Rehosting vs Replatforming vs Refactoring: Which App Migration Strategy Should You Choose?
My boss walked into my office last month. “We need to move our legacy app to the cloud by next quarter,” she said. “What’s the best way to do it?”
I had no idea. But I learned.
Here’s what I discovered about application migration strategies, and how to pick the right one for your situation.
The Problem: Too Many Options, No Clear Answer
When you need to move an application, you face a confusing maze of choices:
┌─────────────────────────────────────────────────┐│ ││ APP MIGRATION APPROACHES ││ ││ ┌──────────────┐ ┌──────────────┐ ││ │ Rehosting │ │ Replatforming│ ││ │ │ │ │ ││ │ "Lift and │ │ Modify │ ││ │ shift" │ │ platform │ ││ └──────────────┘ └──────────────┘ ││ ││ ┌──────────────┐ ┌──────────────┐ ││ │ Refactoring │ │ Rebuilding │ ││ │ │ │ │ ││ │ Rewrite │ │ Complete │ ││ │ code │ │ rewrite │ ││ └──────────────┘ └──────────────┘ ││ ││ ┌──────────────┐ ││ │ Retiring │ ││ │ │ ││ │ Remove app │ ││ └──────────────┘ ││ │└─────────────────────────────────────────────────┘Each approach has different costs, timelines, and outcomes. Pick wrong, and you waste months of work or end up with the same problems in a new place.
What Each Strategy Actually Means
Rehosting: “Lift and Shift”
Think of rehosting like moving houses. You pack everything exactly as-is and move it to a new location. Nothing changes except the address.
What it involves:
- Moving app to new infrastructure (physical server or cloud)
- No code changes
- No architecture changes
- App runs the same way in the new location
When I would use it:
- App works fine, just needs new infrastructure
- Deadline is tight (weeks, not months)
- Budget is limited
- The app doesn’t need optimization
Real example: Moving a Java web app from on-premise servers to AWS EC2 instances. Same JVM, same database, same code—just running on Amazon’s hardware instead of the company’s.
Pros:
- Fastest migration (weeks)
- Lowest cost
- Lowest risk of breaking things
Cons:
- No optimization
- Legacy problems move with you
- Missed opportunity to modernize
Replatforming: “Lift, Tinker, and Shift”
Replatforming is like moving houses but renovating a few rooms before you unpack. You make some changes, but the basic structure stays the same.
What it involves:
- Modifying the platform layer (OS, middleware, runtime)
- Some code changes required
- Architecture largely unchanged
- Adapting to new platform requirements
When I would use it:
- App needs OS upgrade (Windows XP → Windows 10/11)
- Framework needs version upgrade
- Some modernization needed, but not complete rewrite
Real example: Moving a .NET Framework 4.5 app to .NET Core. The code needs adjustments, but the business logic stays the same.
Pros:
- Moderate optimization
- Addresses platform end-of-life issues
- Better than rehosting for long-term value
Cons:
- Takes longer than rehosting (months)
- Requires code changes
- Testing becomes critical
Refactoring: Rewriting for Optimization
Refactoring is like tearing down walls and rebuilding rooms while keeping the house’s foundation. You’re rewriting significant portions of code while preserving the core functionality.
What it involves:
- Rewriting code for optimization
- Major version migrations (Python 2 → Python 3)
- Architecture improvements
- Performance optimization
When I would use it:
- Code has quality issues
- Framework migration required
- Performance problems need solving
- Long-term investment makes sense
Real example: Migrating a Python 2 application to Python 3. The differences between versions are significant enough that simple rehosting won’t work. You need to rewrite parts of the code.
Pros:
- Maximum optimization
- Solves technical debt
- Best long-term value
Cons:
- Most expensive option
- Takes longest (many months)
- Highest risk of bugs
Rebuilding: Starting Fresh
Rebuilding is like building a new house from scratch. You keep the requirements and business logic but start with new technology.
What it involves:
- Complete rewrite in new technology
- New architecture
- New codebase
- Preserved business requirements
When I would use it:
- Language is obsolete (COBOL, old VB)
- Architecture is fundamentally wrong
- Technology no longer supported
- Starting fresh makes more sense than fixing
Real example: Rewriting a legacy COBOL mainframe app as a modern Node.js microservices application.
Pros:
- Most reliable for severely outdated systems
- Opportunity for perfect architecture
- Best developer experience
Cons:
- Most costly approach
- Longest timeline
- Requires extensive testing
Retiring: Removing What’s Not Needed
Sometimes the best migration is no migration at all.
What it involves:
- Identifying redundant applications
- Moving users to alternatives
- Complete removal
When I would use it:
- Alternative solutions exist
- App no longer serves business needs
- Usage has dropped significantly
How to Choose: A Decision Flowchart
I created this decision tree to help pick the right approach:
┌─────────────────┐ │ Is the app │ │ still needed? │ └────────┬────────┘ │ ┌──────────────┴──────────────┐ │ │ NO YES │ │ ▼ ▼ ┌──────────────┐ ┌─────────────────┐ │ RETIRING │ │ Is technology │ │ │ │ obsolete? │ └──────────────┘ └────────┬────────┘ │ ┌────────────────┴────────────────┐ │ │ YES NO │ │ ▼ ▼ ┌──────────────┐ ┌─────────────────┐ │ REBUILDING │ │ Does the app │ │ │ │ work fine? │ └──────────────┘ └────────┬────────┘ │ ┌─────────────────────┴─────────────────────┐ │ │ YES NO │ │ ▼ ▼ ┌─────────────────┐ ┌─────────────────┐ │ What's your │ │ Is it a platform│ │ timeline? │ │ issue? │ └────────┬────────┘ └────────┬────────┘ │ │ ┌──────────────┴──────────────┐ ┌───────────┴───────────┐ │ │ │ │ TIGHT FLEXIBLE YES NO │ │ │ │ ▼ ▼ ▼ ▼ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ REHOSTING │ │ REFACTORING │ │REPLATFORMING│ │ REFACTORING │ └──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘Cost and Timeline Comparison
Here’s what I found about the real costs:
┌──────────────┬────────────┬────────────┬────────────┬────────────┐│ Strategy │ Timeline │ Cost │ Risk │ Long-term ││ │ │ │ │ Value │├──────────────┼────────────┼────────────┼────────────┼────────────┤│ Rehosting │ Weeks │ Lowest │ Lowest │ Lowest ││ │ │ │ │ │├──────────────┼────────────┼────────────┼────────────┼────────────┤│ Replatforming│ Months │ Medium │ Medium │ Medium ││ │ │ │ │ │├──────────────┼────────────┼────────────┼────────────┼────────────┤│ Refactoring │ Months │ High │ High │ High ││ │ │ │ │ │├──────────────┼────────────┼────────────┼────────────┼────────────┤│ Rebuilding │ Many │ Highest │ Highest │ Highest ││ │ Months │ │ │ │├──────────────┼────────────┼────────────┼────────────┼────────────┤│ Retiring │ Varies │ Savings │ Low │ N/A ││ │ │ │ │ │└──────────────┴────────────┴────────────┴────────────┴────────────┘Common Mistakes I’ve Seen
Mistake 1: Rehosting When You Should Refactor
I watched a team rehost a poorly performing app to AWS. Six months later, they had the same slow app—just running on more expensive infrastructure.
The problem: Rehosting doesn’t fix code problems. It just moves them.
When this happens:
- App has performance issues
- Code has technical debt
- Architecture needs improvement
What to do instead: Budget for refactoring. The upfront cost pays off in lower operational expenses and better performance.
Mistake 2: Refactoring When Rehosting Suffices
I also saw the opposite. A team spent months refactoring a stable internal tool that worked perfectly. They could have rehosted in weeks and saved thousands of dollars.
The problem: Over-engineering wastes budget and delays migration.
When this happens:
- App works fine
- No performance issues
- Just needs new infrastructure
What to do instead: Rehost quickly. You can always refactor later if needed.
Mistake 3: Ignoring Interoperability During Replatforming
A team moved an app from Windows Server 2012 to Windows Server 2019. They forgot to check if the app’s dependencies worked with the new OS version. Three weeks of debugging followed.
What to check before replatforming:
- Database compatibility
- Middleware versions
- Third-party library support
- Integration points
Mistake 4: Skipping Security Testing During Fast Rehosting
Speed kills. A team rehosted so fast they forgot security testing. The app had vulnerabilities in the old environment that became even more exposed in the cloud.
Always include:
- Security scan before migration
- Security scan after migration
- Penetration testing for sensitive apps
A Real Decision Example
Let me walk through how I’d decide for a typical scenario:
Scenario: A company has a 10-year-old Java application running on-premise servers. The servers are reaching end-of-life. The app works but has some performance issues.
┌─────────────────────────────────────────────────────────────┐│ SCENARIO ANALYSIS │├─────────────────────────────────────────────────────────────┤│ ││ Given: ││ - Java app (not obsolete) ││ - Works (mostly) ││ - Performance issues ││ - Server end-of-life ││ ││ Decision Process: ││ ││ 1. Is app needed? YES ││ ↓ ││ 2. Is technology obsolete? NO (Java is current) ││ ↓ ││ 3. Does app work fine? MOSTLY (performance issues) ││ ↓ ││ 4. Is it a platform issue? PARTIALLY (server EOL) ││ ↓ ││ 5. Need optimization? YES (performance) ││ ││ RECOMMENDATION: REFACTORING ││ ││ Why: ││ - Platform issue requires some change ││ - Performance needs addressing ││ - Not a complete rebuild needed ││ - Investment in refactoring pays long-term ││ │└─────────────────────────────────────────────────────────────┘What I Learned
After researching migration strategies, here’s what stuck with me:
-
There’s no universal best choice—only the right choice for your situation.
-
Speed vs. optimization is the core tradeoff. Rehosting is fast but doesn’t improve anything. Refactoring is slow but optimizes everything.
-
Budget determines realistic options. Sometimes you don’t have the money for refactoring. Rehosting is better than nothing.
-
Technical debt compounds. Rehosting moves debt to a new location. Refactoring pays it down.
-
Testing is non-negotiable. Every strategy requires thorough testing. The more you change, the more you test.
Quick Reference Card
I made this for my own reference:
┌──────────────────────────────────────────────────────────────┐│ WHEN TO USE EACH STRATEGY │├──────────────────────────────────────────────────────────────┤│ ││ REHOSTING (Weeks, $) ││ ✓ App works fine, just needs new infrastructure ││ ✓ Tight deadline ││ ✓ Limited budget ││ ✓ No optimization needed ││ ││ REPLATFORMING (Months, $$) ││ ✓ OS or middleware needs upgrade ││ ✓ Some code changes acceptable ││ ✓ Moderate budget and timeline ││ ✓ Platform end-of-life issues ││ ││ REFACTORING (Months, $$$) ││ ✓ Code quality issues ││ ✓ Performance problems ││ ✓ Framework version migration ││ ✓ Long-term investment makes sense ││ ││ REBUILDING (Many months, $$$$) ││ ✓ Technology is obsolete ││ ✓ Architecture is fundamentally wrong ││ ✓ Starting fresh makes sense ││ ✓ Budget and time available ││ ││ RETIRING (Varies, Savings) ││ ✓ App no longer needed ││ ✓ Alternatives exist ││ ✓ Usage has dropped ││ │└──────────────────────────────────────────────────────────────┘Final Words + More Resources
My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me
Here are also the most important links from this article along with some further resources that will help you in this scope:
Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!
Comments