TypeScript Developer
for SaaS

Legacy migration succeeds or fails based on risk management, not technical excellence. The most elegant new architecture is worthless if the migration never completes. The strangler fig pattern... incremental replacement of legacy capabilities... succeeds because it delivers continuous value while managing risk. An API gateway like Kong or a custom Next.js edge router sits in front of both systems, routing requests to old or new implementations based on feature flags from LaunchDarkly or PostHog. Each migrated capability goes through phases: shadow mode where the new implementation runs alongside the old but its output is discarded, comparison mode where divergences are logged and reviewed, gradual rollout starting at 1% and ramping over weeks, and finally retirement of the old capability. This pattern means the migration can pause or rollback at any point without disaster. Data synchronization is often the hardest challenge. Debezium or AWS DMS streams change data capture from legacy databases to the new system without modifying legacy code, enabling incremental migration while both systems see current data. This stack is boring on purpose. Legacy migrations already carry enough risk... the tooling choices should not add more. Every component here has been battle-tested on migrations larger than yours, and the operational playbooks are documented.

Legacy migration engagements start with archaeology: understanding the existing system deeply before proposing changes. This means code review, database schema analysis, production log sampling, and structured conversations with the people who've worked with the system for years. Tribal knowledge gets captured in writing before the migration touches a single line of code. Characterization tests pin down current behavior, including the bugs users now depend on. Migration strategy design identifies which capabilities migrate first, what dependencies exist, and where natural seams allow incremental extraction. The strategy produces a phased plan where each phase delivers standalone value and can be paused indefinitely without leaving the system in a worse state. The facade architecture enables incremental migration. I architect the routing layer, design the feature flag taxonomy, and establish the comparison-mode monitoring that catches discrepancies before they reach users. Each phase follows a consistent pattern: build the new implementation, deploy in shadow mode, compare outputs exhaustively for two to four weeks, gradually shift traffic from 1% to 100%, complete cutover, decommission old code paths. Every phase has an explicit rollback procedure tested before traffic shifts. I partner closely with the internal team... my goal is that they own the pattern by the end of the engagement, not that they remain dependent on me for the next phase.