Choosing a migration target without betting on a single vendor slide
Every modernization programme eventually faces the same whiteboard question: where does this code live next year? The answer is rarely a single product name. It is a bundle of runtime choices, operational habits, and regulatory promises.
We use three plain labels with clients—rehost, refactor-in-place, and replace—and force each option to list prerequisites. Rehost might mean lifted VMs with unchanged batch timing; refactor might mean extracting pricing rules behind an API while the old UI limps along; replace might mean a packaged core with twenty custom bridges you must maintain anyway.
Questions that surface the real constraint
Ask who signs off on downtime minutes, not only who owns the Git repo. Ask which reports regulators expect unchanged for seven years. Ask whether your disaster site can run the same charset tables as production. Answers reorder the options faster than benchmark charts.
POPIA and cross-border hosting
South African clients often discover late that a SaaS target stores backups in another jurisdiction. That does not automatically disqualify the option, but it triggers a lawful-basis review you should budget before coding starts.
When two options tie on paper, we run a two-week spike on the riskiest integration only. Spikes cost less than quarter-long regret.