modernization-flow-analysis

Modernization Phase 2: Old Code Analysis

Phase Flow

Phase 2: Old Code Analysis

1. Complete Phase 1 first
2. Process each project separately
3. Analyze code and tests
4. Create original-code-specs files
5. Document legacy services and dependencies
6. Analyze database objects
7. Document interfaces and signatures
8. Document business purpose
9. Analyze usage and visibility
10. List unknowns and assumptions
11. Link implementation and tests

Context

PREREQUISITES: Complete Phase 1 (all reference code specs created)

OBJECTIVES:

• Create complete, factual specification of existing code
• Understand functionality, requirements, edge cases, and usage
• Identify unknowns and create follow-up tasks
• Validate compatibility with modernization target (e.g., Linux support, containerization, cloud-native, etc.)
• Identify services that need replacement (replace with package references or gRPC/HTTP/REST)
• CRITICAL! Identify and maintain original libraries, namespaces, folders, names of classes, methods, interfaces, enums, etc -> so all coding constructs to maintain full names for easy upgrade of dependent libraries (Exception is platform-specific objects and ASYNC methods). Pay attention to modifiers like "ref", "out", "&". Preserve original contracts! Provide additional non-breaking features like access to underlying native objects, enumerators, properties, etc.
• Use appropriate exceptions instead of custom exceptions where appropriate.
• Use and rely on performance optimizations already applied (we must not downgrade!).
• New code will use migrated code, old code will still use old code (so no need to maintain obsolete services or other proxies => use package references OR gRPC/HTTP communication)

Requirements

• MUST process each project separately
• MUST create docs/original-code-specs-<lib/project>.md for each project
• MUST analyze ALL code AND associated unit tests
• MUST use search/grep/tools to discover all relevant details
• MUST document findings with evidence (references to actual code)
• MUST document all service instantiation calls and service providers (including, identifier, purpose, what is used, and references to existing implementation code, identify is it just PROXY or used extensibility or other use case).
• MUST document briefly usage of frameworks/services with a brief list of used features and methods called (no code, but references).
• MUST analyze database schema files (if applicable) to identify database objects used by code:
  • CRITICAL: Database files can be HUGE - DO NOT read/parse entire files!
  • USE codebase_search OR grep to find specific object names (tables, procedures, functions, views, types). Note: grep is more specific with regex patterns, but incorrect regex may not find existing content.
  • Example: If code calls apiGetUserByName, use codebase_search or grep "CREATE PROCEDURE.*apiGetUserByName" to find it
  • Example: If code queries Resources table, use codebase_search or grep "CREATE TABLE.*Resources"
  • Keep database analysis output BRIEF - list only database objects actually used by the code being analyzed, with line references for context.
• MUST list all files and create todo tasks systematically