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

Sometimes the decision arrives from above the argument. A parent company standardizes. A private-equity owner wants one system across six plants. Or you ran the honest test, named the specific things that hurt, and the answer really was the whole system.

I've argued that modernizing Ross almost never means replacing it. Almost never isn't never.

So you're leaving. Fine. Here's the one claim worth making about it:

The destination is not the risk. The departure is.

The part everyone budgets for

Replacing a process ERP is a whole-company project. The destination is usually SAP S/4HANA, Microsoft Dynamics 365 Finance & Supply Chain Management, Infor CloudSuite Food & Beverage, or Aptean's own current process-ERP line. Every one of them has to be configured to how you actually run, while you keep making product the entire time.

Disclosure: I spent eight years at Aptean, where I built the automation layer that wrapped delivery and SharePoint archival around CFB, the Crystal Forms Bundle. Aptean belongs on that list on the merits, and I'm not going to knock a vendor I used to build for.

That project gets a budget, a steering committee, and a partner who does it for a living. Good. None of it is the part I'd worry about.

The part nobody budgets for

Your implementation partner is quietly hoping somebody else hands them clean, complete, correct data out of Ross. Somebody else usually can't.

Standard Ross ships around 1,840 tables before anyone at your company writes a line of code. That number isn't really the problem — plenty of systems are large. The problem is what the database doesn't say about itself.

Take lot traceability, which in a food or supplement plant is the thing you are least allowed to lose. Ross stores lots. Ross stores the links between lots. But the table holding lot-to-lot parentage carries no foreign keys at all — none pointing out, none pointing in. It's an island. There is no relationship in the database connecting a finished lot to the raw lots that went into it. That connection gets reconstructed by code, at runtime. Migrate by walking the relationships and you will get lots, and you will get transactions, and you will not get genealogy. You'll discover this during a recall.

And the connections that do exist are mostly undeclared. The lot number column appears in roughly 135 tables across the system. The database declares it as a foreign key in three of them. So a team that scopes lot data by following the relationships — which is the correct, professional instinct, and what any competent data architect will do — reaches three tables and reasonably believes it has the set. The other hundred-plus are found only by already knowing they're there.

The rules aren't where you'd look for them

Here's what turns a technically successful data migration into a system nobody can explain.

Most of the code in Ross never writes anything. The overwhelming majority of it reads — validating, deriving, pricing, costing, allocating, deciding what a stored value is allowed to mean. So the intuitive plan, find the code that writes and reproduce what it writes, captures a modest slice of your actual business logic and quietly discards the rest. Interpretation leaves no residue in a table dump.

Worse, you often can't tell what something does from what it's called. There is a menu entry named "Count Error Report," classified as a report, whose help text says it catches errors for the count. It runs the same program as the entry named "Update Quantities" — and that program writes to ten tables, including the lot master. Sort your inventory functions by label, rebuild the update, wave off the report as read-only, and you've just dropped a step that changes your stock on hand.

Then there's the logic that isn't code at all. Ross lets you define formulas as text stored in a column: expressions that can reference a constant, a table field, or a measured characteristic of a specific lot. Those formulas drive unit conversions and recipe potency. If you run assays, a unit conversion in your plant can be a function of what a particular lot actually tested at. No standard ERP import has a slot for that. It isn't DML, it isn't EMF, it isn't Crystal, and nothing in the schema marks it as logic — so nothing puts it in front of your implementation partner.

That's the shape of the whole problem. Your Ross system holds fifteen or twenty years of decisions about how your company works, made largely by people who have moved on, recorded in places that don't announce themselves.

Why I can say all that

Because I wrote it down. All of it.

rossdata.dev is a public data dictionary and knowledge graph for standard Ross — every table, every column, the screens, the programs, and which of them touch what. I built it because every serious piece of Ross work starts by re-deriving the same map, and I got tired of drawing it.

It covers vanilla Ross and nothing else. No business data, no custom tables. That limit is the useful part. Your install isn't vanilla; almost none are. A customized system is unreadable on its own and perfectly readable against a baseline, because the baseline is what lets you say this table isn't standard, this program overrides one that is, this column exists nowhere in the shipped product. That's the difference between a migration scope you can argue about and one you're guessing at.

What you're not allowed to lose

Two regulations, stated carefully, because they get cited in the wrong direction.

FSMA 204, FDA's Food Traceability Rule. If you handle a food on the Food Traceability List, you keep traceability records for two years from creation and produce them to FDA within 24 hours of a request, as a sortable electronic spreadsheet. The compliance date was January 2026; FDA has proposed extending it, and Congress restricted enforcement funding in the meantime. The obligations never changed. Only the clock did.

21 CFR Part 11, electronic records and signatures. The common mistake is assuming it blankets your food plant. Largely it doesn't — it lands squarely on dietary supplements and the drug and contract-manufacturing side. Where it does apply, it wants accurate and complete copies in human-readable and electronic form, retrievable for the whole retention period, with audit trails kept at least as long as the records they describe. A PDF archive fails the electronic half. Migrating rows without their change history fails the audit-trail half.

Ross keeps that change history — who altered an expiry date, who approved what — in audit tables that, like the lot trace, aren't reachable by following relationships. An extract that walks the schema will miss the half of the record that proves who did it.

The obligation runs to your company, not to your software. Switching Ross off doesn't retire the duty. It retires your ability to satisfy it.

Where I fit, and where I don't

I am not your S/4HANA integrator, your Dynamics partner, or your Infor VAR. Standing up the destination is a different specialty, and you should hire people who do it for a living.

What I do is the Ross side. Get the data out completely rather than plausibly. Find the rules living in DML, EMF, Crystal and the program catalog and write them down, so they get re-expressed on purpose in the new system instead of quietly disappearing. Untangle the integrations that have to be rebuilt or repointed. Hand your migration team a documented system instead of a shrug.

Two last things

Don't flip it all at once. Run the new system alongside the old, reconcile until you trust it, and cut over in a way you can reason about. A big-bang migration that goes wrong does not offer you a second chance during month-end close.

And keep Ross readable after it stops running — not the license, the records. A read-only archive is a service I offer: your history preserved with its structure documented and queryable, audit trail included, so what you keep is who changed what and when, not just the value that happened to survive. Auditors have never accepted "we turned it off" as a retention policy.

The bottom line

The new ERP is the visible project. The old one is the risky one. Ross holds two decades of your decisions in a system that declares almost none of them, and getting that out intact happens before anyone logs into the new system at all.

Hire the right people to build the new thing. Hire someone who reads Ross to get you out of the old one.

Decided to leave, and now looking at what has to come out of Ross first? The standard system is already documented — rossdata.dev, and how it got built. Yours isn't standard, which is exactly why the private build exists. Let's talk →. Related: how to think about modernizing Ross ERP in 2026.