Mid-Market ERP Readiness: What to Fix Before You Evaluate a Single Vendor
Updated: 2 days ago
For most of a decade the mid-market ERP question had three answers: NetSuite, Microsoft Dynamics, or stay on the accounting package and a lot of spreadsheets. That question is open again. Zoho launched an ERP product in India in February 2026, and while there is no committed date for availability outside that market, the shortlist a US operator writes in eighteen months will not be the shortlist they would have written two years ago.
That is a good reason to get ready. It is not yet a reason to start evaluating.
What decides whether an ERP implementation lands is not which vendor you pick. It is what the vendor is handed on day one. Five conditions do most of that work, and all five are fixable before an evaluation starts — which matters, because each one costs a fraction to fix now compared with what it costs to fix inside a signed build.
The vendor usually gets blamed for a problem the business brought with it
Sit in enough post-mortems and the failure stories rhyme. Go-live slipped two quarters. The data came across wrong and nobody trusted the numbers for months. Half the team kept the old spreadsheet running in parallel. The report the CFO actually wanted was never built, because nobody could agree on what a "customer" was.
None of that is a vendor capability gap. Every one of them is a readiness gap that an implementation team discovered on your behalf, at consulting rates, after the contract was signed.
That is the mechanism worth understanding. An ERP implementation does not create structure. It encodes the structure you already have. Where the structure is ambiguous, the project stops and waits for a decision — and it waits at the most expensive possible moment, with a configured system, a scoped statement of work, and a change-order process standing between the question and the answer.
An ERP readiness assessment is the discipline of finding those decisions early, while they are still free.
The five conditions worth fixing first
These are in dependency order. Each one gets harder if the one above it is unresolved.
1. One settled system of record for each object that matters
Pick the five or six objects the business genuinely runs on — customer, item, order, invoice, employee, maybe location or job — and for each one, name the single system that is allowed to be right.
This sounds trivial and almost never is. Sales says the CRM holds the customer. Finance says the accounting system does. Operations has a warehouse system with its own customer table and a different set of ship-to addresses. All three are partly correct, which is the problem. Until one is designated authoritative and the others are designated downstream, every integration scoped later is a negotiation rather than a specification.
Write it down as a one-page table: object, system of record, who owns it, which systems consume it. If two people in the room disagree about a row, you have just found something worth more than any vendor demo.
2. Master data clean enough to survive a merge
Not perfect data. Data that can be merged without a human adjudicating every conflict.
The practical test is deduplication. Export the customer list from every system that holds one and try to match them. If the match rate is high and the exceptions are a readable list, you are in good shape. If it is not — inconsistent legal names, no shared identifier, three address formats, a "customer" that is sometimes a parent company and sometimes a ship-to location — that is the work, and it is cheaper as a data project you run now than as a migration finding in week six.
The same test applies to the item master, which for anyone carrying inventory is usually worse than the customer list. Duplicate SKUs, units of measure recorded inconsistently, and cost fields nobody maintained each turn into a specific and expensive conversation during a build. The same discipline at CRM scale is laid out in the CRM data migration checklist; the ERP version runs against a wider set of objects and higher stakes, because an ERP carries the financials.
3. Process documented at the level of exceptions
Most companies can describe the happy path in a meeting. Quote, order, pick, ship, invoice. Nobody needs a workshop for that.
What an implementation needs is the exception set. What happens when a customer orders below minimum? When a partial ship goes out? When a return arrives without an RMA? When a job has to be re-costed after the invoice went out? Those branches are where configuration decisions live, and where "we'll just handle it manually" quietly becomes a workaround nobody costed.
Document the exceptions before you evaluate and two things follow. Requirements become testable rather than aspirational, and demos stop being a feature parade — you hand every vendor the same six exception scenarios and watch what happens.
4. A named owner who can decide, not a committee that can escalate
An ERP programme generates a decision a day for months. Most of them are small. Almost none of them are things a steering committee should meet about.
Name one person who owns the outcome and has the authority to settle a cross-department question without escalating it. Not a project manager tracking a plan — someone accountable for whether the system works once it is live. If that person does not exist internally, that is a finding, and it is far better as a finding now than as a discovery in month three, when the programme is stalled on a revenue recognition question nobody feels entitled to answer.
It is also the honest test of readiness. A company that cannot name that person is not ready to sign an ERP contract, whatever the demo looked like.
5. The integration surface mapped, with volumes
An ERP is never the only system. It sits in the middle of a set — ecommerce, EDI, a warehouse system, payroll, payments, whatever industry tooling the business runs on.
Map every connection the ERP will need. For each one, record four things: direction, trigger, record volume per day, and what happens when it fails. That last field is the one everybody skips and the one that decides whether an integration is a weekend of work or a quarter of it.
That map is also the most useful artefact you can carry into an evaluation, because integration is where mid-market ERP projects overrun. It converts "does it integrate with our warehouse system?" — a question every vendor answers yes to — into a specification a vendor either can or cannot meet. Integration is usually the real project, not a line item at the end of one.
Why doing this before an evaluation is cheaper
Each of the five is work either way. The difference is when you pay for it and what it costs.
Before an evaluation, a duplicate customer problem is a data exercise: someone on your team, a spreadsheet, and a week. Inside a signed implementation, the same problem is a change order — scoped, quoted, and sitting on the critical path while a configured system waits.
The asymmetry runs through all five. An undocumented exception before evaluation is a workshop; in user acceptance testing it is a rework cycle. An unnamed owner before evaluation is an org question; in month three it is a stalled programme burning budget.
There is a second return. Readiness work changes what you can ask a vendor to commit to. A business that arrives with a system-of-record table, a clean master data extract, an exception set and an integration map can ask for a fixed estimate and mean it. A business that arrives with a wish list will be quoted time and materials, because nothing else can responsibly be quoted.
That is how we structure it. CodeStringers runs discovery at no risk — you pay for it only if you proceed to implementation — and we guarantee the estimate that comes out of it. If we estimate low, we absorb the difference. That is possible only because discovery does the readiness work above: settling the system of record, testing the data, mapping the exceptions and the integration surface. The guarantee is not confidence. It is the output of having prepared first.
Then evaluate
With those five in hand an evaluation gets shorter and considerably better. You stop comparing feature lists and start handing several vendors the same specification, then compare what each will commit to.
That is also the point at which the reopened ERP question becomes answerable rather than interesting. Whether the right answer turns out to be renewing what you have, moving, building on Zoho when its ERP reaches your market, or taking an interim step that connects the systems you already run, readiness is what lets you judge it.
None of the work is wasted if you stay put. It may be the version that pays off fastest, because a well-owned, well-mapped set of connected systems is the outcome an ERP was supposed to deliver in the first place — and most mid-market businesses already own the tools to get most of the way there. If schedule is the worry, internal readiness rather than the vendor's plan is what sets the pace; we made that case about Zoho implementation timelines.
Preparation is not a delay to the ERP decision. It is the part of the decision you can start today.
Frequently asked questions
What is an ERP readiness assessment?
It is a structured review of whether a business can absorb an ERP implementation, carried out before vendor selection. It covers which system is authoritative for each core data object, the quality of master data, how well processes and their exceptions are documented, whether a single accountable owner exists, and what the integration surface looks like. The output is a list of decisions and fixes, not a vendor recommendation.
How long does an ERP readiness assessment take?
For a mid-market business, a focused assessment runs in weeks rather than months. Most of the elapsed time goes into pulling data extracts and getting the right people in a room to settle system-of-record questions, not into analysis.
Why do ERP implementations fail?
Rarely because the software could not do the job. The common causes are unresolved ownership of data and decisions, master data worse than anyone believed, processes documented only as far as the happy path, and integrations scoped without record volumes or failure handling. All four are readiness problems that surface after signature.
Should we wait for a new ERP option before doing any of this?
No. Every item above is vendor-neutral, and none of it is wasted if you stay put. Readiness work done now is the input to whatever evaluation you eventually run, and it improves how today's systems work in the meantime.
Know whether your business is ready for an ERP before you sign for one.
The ERP Readiness Review is a 90-minute working session plus a written scorecard across master data quality, documented exceptions, integration scope and data ownership. Fixed scope, no obligation. Or see how we approach it.
More on the same problem:
Comments