Legacy Software Modernisation

Incremental decomposition of monolithic applications into independently deployable services -- using the strangler fig pattern so the business continues operating throughout, rather than a big-bang rewrite that halts feature development for 12+ months while a replacement is built in parallel. Domain-driven design (DDD) principles identify bounded contexts -- the natural service boundaries based on business domain ownership rather than technical layer separation. Service extraction proceeds in order of business priority: the component with the highest change frequency and the most deployment friction gets extracted first, immediately delivering faster deployment cycles for that domain while the rest of the monolith continues operating unchanged. API contracts (OpenAPI 3.0 or gRPC service definitions) replace direct in-process function calls, enabling old and new components to coexist during migration with clear interface boundaries. Database decomposition (splitting the shared monolith database into service-owned schemas) is phased separately from service extraction -- attempting both simultaneously is the primary cause of migration failures. Containerisation with Docker and Kubernetes for extracted services provides the deployment isolation and horizontal scaling the monolith lacked. Each extracted service is deployed and validated under real production traffic before the next domain boundary is tackled.

Migration from end-of-life frameworks and languages -- PHP 5.x (EOL December 2018), AngularJS (EOL December 2021), Classic ASP, .NET Framework 4.x running on Windows Server 2012 (EOL), ColdFusion, and legacy Ruby on Rails versions -- to supported modern equivalents that receive security patches and have active community maintenance. Codebase audit identifies the full scope before a migration estimate is given: undocumented business logic embedded in application code (not in specifications), framework-specific API calls that have no direct equivalent, third-party library dependencies with their own upgrade paths, and custom extensions to the framework that must be rewritten from scratch. Feature-by-feature conversion applies test coverage (Jest, Playwright, Cypress for UI; Pytest or Jest for unit tests) as migration progresses -- not after -- so each converted feature has regression tests that confirm behaviour matches the original before moving to the next. Migration targets: PHP 5 to PHP 8.2+ or Node.js; AngularJS to React or Angular 17+; ASP.NET Web Forms to ASP.NET Core or Next.js; VB.NET to C# on .NET 8. The migration preserves the business logic that took years to build while replacing the runtime environment that prevents the system from being maintained cost-effectively.

Migration from legacy database technologies -- on-premises SQL Server 2008/2012 (EOL), Access databases, Oracle 10g/11g, IBM DB2, and proprietary embedded databases like Firebird and Paradox -- to modern managed database infrastructure (AWS RDS, Aurora, Google Cloud SQL, or Azure SQL) that provides automated backups, point-in-time recovery, and managed patching without manual DBA intervention. Schema redesign applied where the legacy data model reflects constraints of the original database platform rather than the actual business domain: denormalised tables maintained for performance reasons that no longer apply on modern hardware; lookup tables built to work around row count limits; NVARCHAR columns storing JSON because the original DB version predated native JSON support. Query optimisation and index strategy rebuilt for the new system: an index strategy designed for 2008 hardware and row counts no longer serves 2024 data volumes, and the query patterns have changed as the application evolved. Migration scripts are tested repeatedly against a non-destructive copy of production data (typically 3 dress rehearsal runs), with row counts, foreign key integrity, and query result comparison validated before the live cutover window is opened. Zero-downtime migration strategies (logical replication during cutover, dual-write period) applied for systems that cannot tolerate downtime for schema migration.

Where a full replacement isn't feasible in a single engagement -- the legacy system is too large, too interconnected, or too business-critical to replace in a controlled timeframe -- an API wrapper isolates it behind a clean, modern interface so consuming applications can be updated independently of the legacy internals. The wrapper exposes RESTful or GraphQL endpoints that translate between modern request/response patterns and the legacy system's SOAP services, proprietary RPC calls, direct database connections, or file-based integrations -- abstracting the implementation details that make the legacy system difficult to work with directly. New features built against the clean API accumulate value and test coverage in the modern layer; the legacy internals are replaced incrementally, module by module, without requiring the consuming applications to change because the API contract remains stable throughout. The anti-corruption layer pattern (from Domain-Driven Design) guides the translation logic, ensuring that legacy data models and terminology don't leak into the new system's domain vocabulary. The approach that makes a 5-year legacy replacement programme possible in annual increments rather than as a single high-risk cutover.

Lift-and-shift migration of on-premises applications to AWS, Azure, or GCP, followed by targeted modernisation of the components that prevent cloud-native operation -- eliminating the hardcoded server paths, on-prem database connections, local file system dependencies, and environment assumptions that were written for physical hardware and break when moved to ephemeral cloud infrastructure. Infrastructure-as-code (Terraform for multi-cloud, CloudFormation for AWS, Bicep for Azure) replaces the undocumented manual server configuration that makes on-prem systems unreproducible; every infrastructure change is code-reviewed and version-controlled rather than applied manually by a sysadmin. Automated CI/CD pipelines (GitHub Actions, GitLab CI, AWS CodePipeline) replace manual deployment procedures that required specific knowledge of the server configuration. Managed services replace components your team previously maintained manually: RDS or Cloud SQL for the database, S3 or Azure Blob for file storage, ElastiCache or Memorystore for caching -- reducing operational burden without rewriting application code in the first phase. Application Performance Monitoring (APM) via Datadog, New Relic, or CloudWatch provides the observability into a cloud-hosted system that most on-prem deployments lack, enabling proactive issue detection rather than reactive incident response. The migration from a single-point-of-failure on-prem server to multi-AZ cloud infrastructure with automated backups and auto-scaling.

Structured audit of a legacy codebase with no documentation -- identifying what the code actually does, mapping the data model, documenting the business rules embedded in application logic, and producing a dependency map that shows what connects to what. Static analysis tools (SonarQube for code quality metrics, Understand for dependency mapping, Doxygen for auto-extracting inline documentation) identify dead code, circular dependencies, and undocumented entry points that only become visible programmatically across tens of thousands of lines. The data model reverse-engineering extracts entity relationships from the live database schema (including implicit constraints enforced in application code rather than the DB) and documents the business domain those tables represent -- the difference between what the schema says and what the business actually means. Business rule extraction is the most labour-intensive phase: rules embedded in stored procedures, conditional logic, and hardcoded lookup values are documented in plain language with the application path that triggers them. The output is a structured assessment report covering scope, maintenance cost estimate, risk inventory, and a replacement sizing -- the information a business needs to make a modernisation decision rather than a blind rewrite that discovers complexity after the budget is committed.