80% of the lifetime cost of a piece of software goes to maintenance
Software migration is quite common among enterprise software, though it's probably not the most exciting puzzle to solve in the engineering fields. I have worked with some legacy systems and felt the pain of dealing with them, so I'd share some thoughts or strategies I've used before. Though there are some concerns worth more considerations than others, namely code synchronization (DRY principle) and backward compatibility (contract design) etc.
Non-incremental
Rewrite
That's migrating by rewriting the entire application. Due to restarting from scratch, it has less baggage in longer term but takes longer time span as well, but sometimes it's inevitable to do a full rewrite for tech stack overhauling or avoiding maintenance nightmares.
Pros & Cons
- It trades agility for simplicity (brute force)
- It creates a lot of duplications
- It has high cost of communication to synchronize changes (versioning) due to the duplications
Incremental
Shared Module
That's migrating by extracting common logic into a shared module. It aims to contain changes (during migration) in a shared module, so that migrations along with feature development or bug fixes won't interfere with each other and thus can be carried out more incrementally.
Pros & Cons
- It trades simplicity (upfront design) for agility
- It minimizes duplication to reduce cost of communication
I break them down into following phases.
Beginning phase
- Modules are migrated from Legacy App to Shared Module in a “bottom-up” manner
- New App just gets bootstrapped
- Short duration
Transitional phase
- Modules are migrated from Legacy App to Shared Module and from Shared Module to New App
- New App runs side by side with Legacy App
- Long duration
Ending phase
- Modules are migrated from Shared Module to New App in a “top-down” manner
- Legacy App gets deleted
- Short duration
Other resources
