How to actually leave Ross (if you really have to)

I've written before that modernizing Ross almost never means replacing it. That's true, and it's still my default advice. But "almost never" isn't "never," and sometimes the decision is genuinely made: the business is moving off Ross to Dynamics, or Odoo, or SAP, and the question is no longer whether but how without wrecking the company on the way out.

So let's take that as given. You're leaving. Here's the thesis, and it's the opposite of what most of the migration conversation focuses on: the hard part of leaving Ross isn't standing up the new ERP — it's getting your data and your business logic out of Ross intact. That's the part that blows budgets and timelines, and it happens to be the part a Ross specialist is actually built for.

First, be honest that it's a big project

Replacing an ERP is a multi-year, whole-business undertaking, and anyone who tells you otherwise is selling something. The new system — whether it's Microsoft Dynamics 365, Odoo, or SAP — has to be configured to how you actually run, your people have to be retrained, and the business has to keep operating the entire time. This is not a lift-and-shift, it's not a weekend, and the failure stories are legendary for a reason. If you're going to do it, respect it. The companies that get hurt are the ones that treated it like an IT project instead of a business transformation with an IT component.

I'm not here to talk you out of it — you've decided. I'm here to make sure the specific part that tends to go wrong doesn't.

The part everyone underestimates: getting data out of Ross

Here's what the new-ERP implementation partner is quietly hoping someone else handles: extracting clean, complete, correct data out of Ross and handing it over in a shape their system can actually ingest.

This is hard in a way that surprises people, because Ross is not a friendly place to extract from. The schema carries decades of history and quirks. There's business logic buried in DML, EMF processes, and Crystal reports that never got written down anywhere else — rules about how your company calculates cost, handles lots, prices customers, and closes jobs, encoded in places the new system's team can't read. And you have years of lot and batch history that you are, in several industries, legally required to preserve and be able to produce.

Underestimating this is the classic way these projects slip. The implementation team assumes the data will "just come over," discovers Ross doesn't give it up cleanly, and now the timeline is a rumor and the budget is a memory. The extraction is not a formality. In a Ross migration it's frequently the single riskiest workstream, and it wants someone who knows where the bodies are buried in that schema.

Preserve the logic, not just the rows

The subtle trap is thinking migration is about moving data. It's about moving meaning.

Your Ross system doesn't just hold records — it holds accumulated decisions about how the business works, often in customizations and reports written by people who are long gone. If you migrate the rows and lose the logic, you arrive in your shiny new ERP having faithfully transferred numbers you can no longer explain. So part of the exit is excavation: surfacing what the DML and EMF and Crystal were actually doing, so the business rules can be re-expressed deliberately in the new system rather than silently dropped. That's not data work. It's archaeology with a purpose, and it's exactly the kind of thing that requires reading Ross fluently.

Where I fit, and where I don't

Let me be clear about the division of labor, because honesty is the whole brand. I am not going to pretend to be your SAP implementation partner or your Dynamics VAR. Standing up and configuring the destination ERP is a different specialty, and you should hire people who do that for a living.

What I own is the Ross side of the exit: extracting your data cleanly and completely, surfacing and documenting the business logic trapped in the old system, untangling the integrations that have to be rebuilt or repointed, and handing the migration team something clean instead of a mystery. It's the part that needs someone who knows Ross cold, and it's the part that's hardest to hire for — because the pool of people who understand Ross deeply is exactly the pool that's retiring. Getting out of Ross well is, ironically, one of the best reasons to have a Ross expert on the project.

Don't big-bang it, and keep Ross readable

Two pieces of hard-won discipline for the cutover itself.

Don't flip everything at once if you can possibly avoid it. Run the new system in parallel where you can, reconcile it against Ross until you trust it, and cut over in a way you can reason about. A big-bang migration that goes wrong doesn't give you a second chance during month-end.

And keep Ross readable after you leave, at least for a while. You'll need it for historical lookups, audits, and the inevitable "what did we actually do in 2023?" question. Turning the old system off the day the new one goes live feels like closure and is usually a mistake. The lights can dim gradually.

The bottom line

If you've truly decided to leave Ross for Dynamics, Odoo, or SAP, the destination isn't the risk — the departure is. Getting your data and business logic out of Ross intact is the hard, underestimated, project-defining part, and it's the part I actually do. Bring in the right people to build the new system, and bring in someone who knows Ross to get you cleanly out of the old one. That's how the exit goes well instead of becoming a cautionary tale.

Leaving Ross and staring down the data-migration problem? Getting cleanly out is exactly my side of that project. Let's talk →. Related: how to think about modernizing Ross ERP in 2026.