ERP in 30 days: the honest guide to fast implementation without disruption

Ask any vendor how long an ERP implementation takes and you will hear somewhere between six and eighteen months. That number is real. It is also mostly not engineering time.

We deploy in thirty days. People assume this means we are cutting scope. We are not. We are cutting the part of the project that was never adding value in the first place.

Where the eighteen months actually goes

A conventional ERP implementation spends its first three to five months on discovery and configuration. A consultant sits with your team, learns what a batch number means in your business, learns that your invoices need a separate reference for the distributor, learns that your warehouse counts in cartons but your accounts count in units.

Then they configure a generic system to accommodate all of it.

That work is real. The problem is that it gets thrown away. The next pharmaceutical distributor who buys the same generic ERP pays for the same discovery, because nothing learned in your implementation is embedded in the product. It lives in your configuration file.

We build industry platforms instead. PharmFlow already knows what a batch number is. It knows expiry dates drive picking order, that GDP requires a temperature record against a movement, and that a blocked credit account must stop a dispatch rather than flag it afterwards. None of that is configured. It is the product.

That deletes the discovery phase almost entirely, and the discovery phase is where the six-to-eighteen months lives.

What the thirty days is spent on

Days 1–5: data extraction and mapping. We take what you have: spreadsheets, an old system’s export, in one case a decade of handwritten ledgers photographed page by page. We map it to the platform’s structures and tell you within the first week what is clean, what is ambiguous, and what is unrecoverable. That last category is always larger than clients expect, and finding it in week one rather than month five is most of why this works.

Days 6–15: migration and parallel entry. Historical data goes in. Your team starts entering new transactions in both the old system and the new one. This is the deliberately uncomfortable part and we do not skip it. Parallel entry is how you find the case nobody mentioned in discovery, because someone will hit it in week two and say “oh, we do it differently for that supplier.”

Days 16–25: training against your own data. Not a demo dataset. Your stock, your customers, your suppliers. People learn a system far faster when the screen shows names they recognise. Training happens role by role, and the warehouse team never sees the credit control screens.

Days 26–30: cutover and stabilisation. The old system goes read-only rather than off. We stay on-site or on-call for the first full billing cycle.

What can go wrong

Two things, and both are honest risks worth stating before you sign anything.

The first is data quality. If your existing records are bad, thirty days is not enough to make them good. We will migrate them accurately and they will be accurately bad. Cleaning is a separate piece of work and we price it separately, because pretending otherwise is how implementations quietly become nine-month projects.

The second is decision latency. The thirty days assumes someone on your side can make a decision within a day. Every implementation that has run over has run over because a question sat in an inbox for a fortnight. We name that person in the contract now.

Where this does not apply

If your operation genuinely does not resemble anything we have built for, a pre-built industry platform is the wrong tool and we will say so. Thirty days works because ninety percent of the system already exists. When it does not, you want a generic ERP and a long implementation, and you want a vendor who will tell you that rather than sell you a fast deployment that does not fit.

That is the actual trade. Speed comes from specificity. A platform built for one industry is very fast for that industry and useless outside it, which is exactly why we build six of them instead of one.