Overview
Legacy system migration involves replacing or modernizing outdated systems while maintaining business continuity. This is challenging work: understanding undocumented code, managing risk, and building incrementally while the old system runs. Migrations fail more often than greenfield projects because legacy systems contain business logic no one remembers and dependencies no one documented.
Success requires patience, systematic approach, and understanding the legacy system before replacing it. The strangler fig pattern—gradually replacing functionality while keeping the old system running—is the most reliable approach. Companies like Amazon and LinkedIn have successfully migrated massive legacy systems over multiple years.
For hiring, legacy migration is less attractive to developers than greenfield work. You need engineers who find the challenge interesting, have realistic expectations about the work, and won't get frustrated by slow progress. Look for candidates with experience in large-scale refactoring and system archaeology.
The Reality of Legacy Migrations
Legacy migrations are among the most challenging engineering projects. Understanding why they fail helps you hire the right people and set realistic expectations.
Why Legacy Migrations Fail
Undocumented Behavior:
Legacy systems contain business logic no one remembers. The code is the documentation—and it's often unclear.
Unknown Dependencies:
Systems integrate in ways that aren't documented. Breaking one thing breaks others unexpectedly.
Business Risk:
The legacy system runs the business. Mistakes during migration have real consequences.
Stakeholder Impatience:
Business wants migration done quickly. Technical reality requires careful, incremental work.
Technical Debt Compounds:
Each shortcut in the migration creates future problems. Pressure to move fast creates more legacy code.
Migration Strategies
Big Bang Migration
Replace everything at once. High risk, shorter timeline.
When it works:
- Small, well-understood systems
- Low business risk tolerance for parallel systems
- Strong testing coverage possible
Why it usually fails:
- Unknown behaviors discovered too late
- No fallback if things go wrong
- Pressure leads to incomplete migration
Strangler Fig Pattern
Gradually replace functionality. Lower risk, longer timeline.
How it works:
- New functionality goes in new system
- Migrate existing features incrementally
- Old system shrinks until it can be retired
Why it's recommended:
- Continuous delivery of value
- Fallback to old system available
- Issues discovered incrementally
Parallel Run
Run both systems, compare results. Moderate risk, highest complexity.
When it works:
- Critical systems requiring validation
- Data consistency is paramount
- Resources available for dual maintenance
Skills Assessment for Migration Engineers
Essential: Understanding Legacy Systems
Reading Old Code:
Can navigate unfamiliar, poorly structured code. Doesn't give up when documentation is missing.
Reverse Engineering:
Can discover business rules from code behavior. Asks the right questions.
Patience:
Migrations take longer than expected. Need engineers who persist through frustration.
Essential: Building Modern Systems
Current Best Practices:
Knows modern architectures, patterns, and tools. Can design the target system.
Incremental Delivery:
Can break migration into phases. Delivers value continuously.
Migration-Specific Skills
Risk Management:
Identifies what can go wrong. Plans for rollback. Communicates risk clearly.
Data Migration:
Understands data transformation, validation, and reconciliation. Data is often the hardest part.
Testing Strategies:
Knows how to validate migration correctness. Builds confidence incrementally.
Hiring Challenges for Migrations
The Attraction Problem
Legacy work isn't glamorous:
Most developers prefer greenfield projects. "Working with old COBOL code" isn't exciting on a resume.
How to frame it:
- Emphasize the challenge and impact
- "Modernizing a system that runs $X billion in transactions"
- Highlight learning both old and new systems
- Show career growth opportunities after migration
Finding the Right Fit
Rare combination needed:
- Patience to work with legacy code
- Skills to build modern systems
- Realistic about migration challenges
Where to look:
- Engineers who've done migrations before
- Consultants with modernization experience
- Senior engineers who value challenge over novelty
Team Composition for Migrations
Small Migration (5-20 person-months)
Team:
- 2-4 full-stack engineers
- Domain expert (or access to one)
- Part-time QA support
Key roles:
- Someone who understands the legacy system
- Someone who knows modern architecture
- Someone who can manage data migration
Large Migration (50+ person-months)
Team:
- Legacy system experts (2-3)
- Modern system architects (2-3)
- Data migration specialists (1-2)
- QA engineers with domain knowledge (2-3)
- Project management
Phased hiring:
- Start with analysis and planning team
- Add development capacity for execution
- Maintain legacy knowledge throughout
Setting Realistic Expectations
Migrations almost always take longer than planned. Set expectations with stakeholders and candidates:
- Unknown dependencies will emerge
- Business requirements will change during migration
- Testing reveals unexpected behaviors
- Data migration is harder than it looks
Legacy Migration Success Factors
What Makes Migrations Succeed
Deep Understanding First:
Successful migrations start with understanding, not building:
- Document existing system behavior thoroughly
- Identify all integrations and dependencies
- Understand the business rules embedded in code
- Map data flows and transformations
Incremental Delivery:
The strangler fig pattern works because it delivers value continuously:
- Each phase provides working functionality
- Issues are discovered and fixed incrementally
- Stakeholders see progress throughout
- Fallback to old system remains available
Strong Testing:
Migration testing requires special attention:
- Parallel running to compare outputs
- Data validation at each phase
- Regression testing for existing functionality
- Performance testing under realistic load
Building the Right Team
Diverse Skills Needed:
Migration teams need multiple perspectives:
- Engineers who can read and understand legacy code
- Engineers who can design modern systems
- Data specialists for migration and validation
- Domain experts who understand business rules
Patience and Persistence:
Migration work is often frustrating:
- Undocumented behaviors require investigation
- Progress can feel slow
- Stakeholders may not understand complexity
- Technical debt from the past creates challenges
Hire engineers who find satisfaction in solving these puzzles, not those who will become frustrated and disengage.
Managing Migration Projects
Stakeholder Communication
Set Realistic Expectations:
Migrations take longer than expected. Communicate this early:
- Provide ranges, not fixed dates
- Explain why estimates are uncertain
- Update regularly as you learn more
- Celebrate incremental progress
Visible Progress:
Show stakeholders that work is happening:
- Regular demos of migrated functionality
- Metrics on migration progress
- Clear communication about challenges
- Transparency about timeline changes
Risk Management
Identify Risks Early:
Common migration risks include:
- Data quality issues in legacy system
- Undocumented business rules
- Integration dependencies
- Performance differences
Plan for Rollback:
Always have a way back:
- Maintain ability to revert to old system
- Test rollback procedures
- Keep old system operational during transition
- Plan for gradual cutover, not big bang