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