Replace the Vendor by Running Around It

Don't rip out an entrenched ERP add-on. That's the whole position, so let's state it before the reasoning: you run beside it, you write to the fields it already trusts, you leave its workflows on, and you let the client pick the cutover date. Once the replacement works, you stop fixing the old path entirely. A defect there stops being a bug to patch and becomes a reason to repoint the workflow to the new system instead. And before the vendor goes, you harvest its history, because that history is the best labeled data you'll ever get for free.

If you came here deciding between rip-and-replace and coexistence when you're replacing ERP add-ons, that's the answer. Coexistence wins, and it isn't close, for reasons that have nothing to do with caution and everything to do with what an add-on actually is by the time anyone decides to replace it.

Why rip-and-replace fails inside an ERP

Nobody sets out to build hundreds of workflows, scripts, saved searches, and custom fields around a single add-on. It happens the way debt happens: one saved search this quarter to handle a customer's weird routing rule, one script next quarter because the saved search couldn't cover an edge case, one custom field the quarter after that because someone in operations needed a place to note something the form didn't ask for. Three years in, the add-on isn't a feature anymore. It's a layer of the business's actual operating logic, expressed in a vendor's schema instead of your own.

That's the part rip-and-replace ignores. The plan usually reads clean on a slide: migrate the data, cut over on a weekend, decommission the old system Monday morning. What that plan is actually proposing is a single, simultaneous swap of every one of those hundreds of dependent behaviors, verified in advance by people who don't have a complete list of what depends on what. Nobody does. The saved search from three years ago that finance still runs every Friday isn't in anyone's migration checklist, because nobody remembers writing it.

We've written elsewhere about why a monolithic cutover is the wrong shape for operational software generally. Modular vs Monolithic Software: Operations Guide covers the general case. Replacing an entrenched ERP add-on is that same argument with the stakes turned up, because you're not choosing between two ways to deploy new capability. You're choosing whether to keep the business running on the same day you swap out a system it has been quietly leaning on for years.

There's a second reason rip-and-replace fails that's less about risk and more about honesty: you don't actually know what the add-on does until you've watched it run for a while next to something else. Documentation lags reality in every system we've touched. The only reliable way to find the workflows nobody wrote down is to build the replacement, put it next to the original, and watch where the two disagree. Rip-and-replace throws that diagnostic away. Coexistence is built on it.

Coexistence mechanics

The shape we used: additive only, forward only, no historical backfill, separately signed work documents, with the single biggest risk (sending the same thing twice) handled by switching off one vendor deployment at go-live rather than trying to referee two live systems fighting over the same action.

Each of those choices earns its place.

Additive only means the new system writes to fields the old system already trusts, instead of asking the old system to accept writes from a source it's never seen. The add-on doesn't know or care that a different pipeline is now populating a field it reads. As far as the add-on is concerned, the field just got filled in, the way it always has been. You're not asking it to change its behavior. You're feeding it the same inputs from a second source, in parallel with the first.

Forward only means you don't touch history. No re-processing three years of records through the new logic to make the two systems agree retroactively. Historical backfill is where these projects quietly become archaeology, and archaeology is not the job. The job is making tomorrow's orders flow correctly. Yesterday's orders already went through the old path and don't need to be re-litigated.

No historical backfill is really a stronger version of forward only. It's a boundary line: the new system's authority starts at a point in time, not before it. That line matters because it stops a specific bad habit, which is going back to "fix" an old record to make a report look consistent. Reports can carry a note explaining the transition. They don't need every historical row rewritten to match a new schema.

Separately signed work documents is the unglamorous detail that makes the whole thing auditable. When two systems are both producing paperwork for the same operational event, during the coexistence window, you need every document tied to a system, a version, and a signature, so that when something is wrong six weeks later you know instantly which path produced it. Skip this and you get a debugging session that starts with "which system made this," which is a question you should never have to ask.

The double-send problem is the one that actually keeps you up at night, and it deserves its own paragraph, because it's the risk that made the rest of the design necessary. If both the vendor add-on and the new system are live and wired to the same downstream action, meaning a customer confirmation, a warehouse pick, a supplier notification, then coexistence can produce the same real-world event twice. Sending an order confirmation twice is annoying. Releasing the same production run twice is not. The fix is not clever reconciliation logic sitting on top of both systems trying to guess which one already fired. The fix is simpler and more reliable: at go-live, you switch off one vendor deployment, the specific one that would double-fire against the new path, while leaving the rest of the add-on's workflows running untouched. You don't disable the add-on. You disable the one wire that would cause a collision, and you do it deliberately, not as an afterthought discovered in an incident review.

This is the same logic behind parallel operation as a deployment pattern generally: run new and old side by side, let the new system prove itself against live conditions instead of a staging environment, and only remove the old path once you've watched the new one hold up under real volume for a real stretch of time. Parallel Operation Deployment: Zero-Disruption Automation goes into the general mechanics if you want the pattern without the ERP-specific edges. What's specific to an entrenched add-on is the density of hidden dependents, and that's exactly why the additive-only, no-backfill, one-deployment-off shape earns its keep here more than almost anywhere else.

The stop-fixing rule, and the slip that made it a rule

Here's the part that isn't intuitive until you've lived through it.

Once the replacement works, meaning it's handling live volume correctly and you trust its output, you stop fixing defects on the old path. Full stop. A bug on the retiring system is no longer a bug to triage and patch. It's a signal that this particular workflow, customer, or edge case needs to be repointed to the new system now, instead of later.

This sounds obvious in the abstract and is hard in practice, because the instinct to fix what's broken in front of you is strong, and it doesn't check whether the thing in front of you is scheduled for retirement. We know this because we did it ourselves. Partway into a coexistence window, someone on our team found a defect on the retiring path and started fixing it, the way you'd fix any bug, because that's the reflex every engineer has been trained into since their first job. It took a few minutes to catch: we were sinking effort into a system that had a defined exit date, instead of using the defect as the evidence it actually was, which was a signal that this specific workflow needed to move to the new system now rather than at the originally planned pace.

We withdrew the fix within minutes of starting it. The specifics of the case don't generalize enough to be useful here, but the pattern does, and it's why never-fix-the-old-path is now a written rule on every coexistence project we run, not a norm we hope people remember. Written rules survive a busy week. Norms don't.

The logic underneath the rule is straightforward once you see it: every hour spent stabilizing a system you're retiring is an hour not spent moving its remaining dependents onto the system that replaces it. Worse, a "fixed" defect on the old path can look like evidence that the old path is fine, healthy, worth keeping around a little longer, which is exactly the wrong signal to be feeding a decision that should be trending toward zero. Bugs on the retiring system aren't obstacles. They're a punch list, and the correct response to every item on it is migration, not maintenance.

This connects to a broader point we've made about human-in-the-loop review not being a safeguard by default: a checkpoint only does something if the people running it are willing to act differently based on what it tells them. Human-in-the-Loop Is Not a Safeguard makes that argument in a different context, but the underlying point is the same one that almost got us here. A signal is only useful if you let it change your behavior. A defect on a system you're retiring is a signal telling you to retire it faster. Fixing the defect instead is choosing not to hear the signal.

Harvest before removal

Before the vendor goes, and this step is not optional, you pull its filing history out and keep it.

Here's why that history matters more than almost anything else in the project. Every record that add-on ever produced represents a real decision made by a real person operating under real constraints: what to route where, what exception to grant, what field to leave blank because the situation didn't fit the form. That's labeled data in the fullest sense, not a synthetic training set someone constructed to approximate reality, but the actual record of how humans handled the actual mess of the operation for as long as the add-on was in service. Once you decommission the system, that data doesn't get easier to reconstruct. It gets impossible.

We treat this the same way we treat any pool of human decisions on a project: as the highest-value evidence available for building and checking the systems that come after it. It's the same instinct behind treating a checker's catch rate as something you measure rather than assume, discussed in Who Checks the Checker? Managing Agents Is a Measurement Problem. You don't get a second chance to capture what an add-on's filing history recorded once the add-on is off. Harvest it before removal, structure it, and keep it as ground truth for validating the new system's behavior against years of real decisions, not just the handful of test cases someone wrote down before go-live.

Who owns the cutover date

One more piece of the position, and it's not a minor one: the client picks the cutover date, not the build team.

This isn't deference for its own sake. It's a recognition that the client knows things about their own calendar that no amount of technical readiness can substitute for. Maybe there's a seasonal peak where nobody wants any change in flight. Maybe a key person who understands the add-on's history is out for two weeks and needs to be present for the transition. Maybe there's a fiscal quarter close that shouldn't overlap with any period of dual-system uncertainty. The build team can say the replacement is ready. Only the client can say the business is ready to stop running two systems side by side, and those are different questions.

Coexistence is what makes that client-owned date possible in the first place. If the plan were a single cutover weekend, the date would be forced by technical readiness, a fixed migration window, and whatever risk tolerance the build team was willing to accept on behalf of a business they don't run day to day. Coexistence removes that constraint. The new system can be live and proving itself for weeks or months while the client decides, on their own schedule and their own risk read, when the old path finally goes dark.

The build-vs-buy shape of this decision

Replacing an ERP add-on is a smaller, sharper version of the build-vs-buy question we write about constantly, because the add-on itself was almost certainly someone's answer to "buy something close enough and bend the workflow to fit it." Years later, the bending shows up as hundreds of dependent workflows nobody fully mapped. The replacement doesn't need to repeat that mistake. Model the actual business logic chains the add-on has been standing in for, deploy the replacement incrementally against those chains, and let the vendor's own history tell you whether the model is right. Business Logic Chains Explained: Why RPA Is Just Button-Clicking is worth reading alongside this if you're trying to figure out whether what you're replacing is a workflow tool or something closer to the operation's actual decision logic wearing a vendor's interface.

If you're staring down an entrenched add-on right now, hundreds of workflows deep, and someone on your team is proposing a clean cutover weekend, don't do it. Run beside it instead. Write to the fields it trusts, leave its workflows running, let your team pick the date when they're actually ready, and treat every defect on the old path as a reason to move faster, not a reason to patch and wait. Harvest the history before it's gone. That's the only version of this project that doesn't ask you to bet the operation on a single weekend.

If you're mapping this out for your own ERP add-on and want a second set of eyes on where the coexistence boundary should sit, book a discovery call. We'll walk through what we'd model first.