Rip-and-replace is a mood, not a strategy
Teams reach for replacement when the current stack feels embarrassing — duplicate entry, reports nobody trusts, five logins for one job. Sometimes they are right: end-of-life products, compliance forcing migration, a vendor relationship that already collapsed. Often the faster win is to connect what you have with a thin, owned integration and clear ownership while you prove the process is actually stable.
Replacement is a headline. Integration is a Tuesday fix. The difference matters when you are already paying for three subscriptions and the pain is a single handoff that nobody owns.
Good candidates for integrate-first
The best candidates are usually obvious once you look at them plainly. A single handoff being re-keyed every day — CRM to finance invoice, depot completion to billing, web form to job queue. One report the board asks for that still requires export and a VLOOKUP. A customer fact that lives in two places but only disagrees on Tuesdays. A portal that could read from an API instead of a mailbox.
These slices have measurable relief: hours saved, errors removed, one fewer argument about which version is right at month-end. They also produce evidence for or against a bigger rip-out later — you learn whether the process is stable before you bet a year on migration.
Bad candidates: when connect is denial
Connect-first stops making sense in certain situations. When the core product is end-of-life or unsupported, patching it is not a plan. When security or compliance forces migration, you do not get to defer it. When the integration would be twelve brittle scripts nobody will maintain, you are creating debt with extra steps. And when the real problem is no system of record at all — wiring two liars together does not create truth. If the spreadsheet has already become the business brain, that article says more about where you are.
How to decide in one meeting
Draw start and stop for the painful slice on a whiteboard. Count the systems touched. Ask honestly: if we fixed one queue and established one source of truth in ninety days, would leadership still demand a full replacement? If yes, understand why — often it is UX shame rather than genuine ops pain. If no, integrate first and defer the bigger vision deliberately.
Check when to automate versus stay manual before you automate the wrong bridge. Not every handoff deserves code. Some deserve discipline and a named person updating one field at close-out.
Make the integration owned, not orphaned
Assign one human who answers when the sync fails at 07:00. Document the expected latency — near-real-time or nightly batch. Define the failure behaviour: does ops fall back to a spreadsheet, or does work stop? Without those answers, the integration becomes a hero project. Heroes go on holiday.
Proof before the big bet
Run the integration for four to eight weeks alongside a parity report — same counts in both systems within an agreed tolerance. Capture exceptions in a shared log. They will tell you whether the next phase should be more integration or honest replacement. Share the results with finance: hours saved, errors removed, month-end arguments avoided. That evidence beats a slide that says "modern platform."
If integrate-first succeeds, you may still replace later — but from strength, with a stable process and realistic requirements, rather than from panic after a bad demo season. The guidance on vendor demos and your workflow applies when replacement RFPs come back around.
Book a systems review to pressure-test integrate versus replace in your context. Custom build and integration when the case holds, and care when it is live and must not rot in the next busy quarter.