This is Part Two of a two part series. Part One is here

NOTE: I don’t actually feel like writing this whole thing right now. I’m going to expand it later, possibly with its predecessor.

What I have learned about incremental in-place upgrades of existing applications

• Incremental upgrades can take a very long time to “complete”, but you get immediate marginal benefits if you can make releases early and often.
• A “long time” to “complete” could be never.
  • “Never” might actually be OK if there’s enough value with little effort.
• “Marginal” here means “at-the-margin”, not small.
• If updating old dependencies, you will find that they come in 4 basic categories:
  • A version that is still supported is available, with no breaking changes - these you should just do, right away, because they’re so easy. Have an intern do it.
  • A single dependency with a defined migration path - these you should probably do, depending on how bad the migration path is.
  • Dependencies with no supported later version available - these you should just throw away, if you can get away with it.
    • I feel like a lot of XML parsers end up here. Your application doesn’t need 5 XML parsing libraries.
    • If you really, genuinely, truly, absolutely must have this dependency to do whatever it does, and it really, genuinely, truly, absolutely has no replacement, then there’s probably some really simple way to do whatever that dependency does yourself.
  • Dependencies with their own tree of dependencies underneath them that also need updating - this is where you get into trouble. The transitive dependencies can get so complicated that you have to compare the effort between updating the ball of mud and just rewriting the whole thing.
    • These cases should shape the “upgrade vs. re-write” decision.
• Stakeholder buy-in is essential for a successful in-place upgrade.
  *