CRM Project Before the ERP Replacement

Why the order gets decided the same way almost every time

In most manufacturing and engineering businesses the ERP is the only system that has ever held customer data, and there is no CRM at all. When the ERP comes up for replacement, the sequence is usually settled without much debate: replace the ERP first, then buy the CRM from the same vendor. It sounds like architecture. It is a deferral.

Count the time that sequence actually costs. The new ERP goes through selection, rollout and stabilisation. Then the organisation needs a break, because an ERP programme is exhausting. Only after that does the CRM discussion start, and it gets specified in the same level of detail. Through all of it nobody can say what the pipeline looks like, which accounts need attention, or where the sales team spends its hours.

Our view: sequence against the bottleneck, not against the vendor. The bottleneck is almost never master data. It is the missing view of what sales is doing right now.

What a first CRM has to do before the ERP is live

The assumption behind the usual order is that a CRM needs clean data from the new ERP first. For the part sales is actually missing, that is not true. A first build shows which deals are running, how far along they are, and what happened with each account most recently. None of those three views depends on material masters or price calculation.

That means a first build can be set up and trained long before the ERP goes live. By the time the integration arrives, the sales team is already working in the system — and adoption is the hard part of any rollout. A CRM rarely fails on technology. It fails because nobody uses it.

Our view: a first build is technically independent of the ERP, so we build it first. The months before ERP go-live are the cheapest adoption time you will ever get.

How to size the first build when there is no legacy system

The usual blocker is not missing product knowledge. It is missing scope. A sales leader has budget and a mandate to put something in place quickly, and still cannot say what the first version should do. Perfect forecasting comes later, that much is obvious. What belongs in it now?

The question that closes the scope is not a technical one: which management decision is coming up in the next few months that currently fails for lack of visibility? If you intend to stop actively serving the lower customer segment, you need to see where activity is still happening there anyway. That single decision produces the scope on its own.

Our view: scope comes from a pending decision. A catalogue describes possibilities; a decision describes need.

Is an interface to an ERP you are switching off worth building?

This is where the most expensive misjudgement sits, and it feels like diligence. Teams that pull the CRM forward want to do it properly, so they build a bridge to the existing ERP. That bridge almost never pays for itself, because its target disappears within months.

Older systems frequently have no usable interface at all. Connecting them becomes an investment in its own right, and an investment does not amortise over a remaining runtime of a few months. The more honest answer is a deliberately defined gap: for a manageable number of new records per day you transfer manually for the transition, and the real integration gets built against the new ERP.

The deciding factor is the volume model, not instinct. Count how many records per day genuinely need to move between the systems, and weigh that against the effort of connecting them. At a handful of transactions a day the gap wins. At hundreds it does not, and then the real question is whether the old ERP is being retired as quickly as planned.

For anyone worried that a deferred integration becomes a monster project later: it does not, when it runs against a current system. At SpotCom it took 3 months to integrate HubSpot with on-premise ERP with HubSpot to increase sales capacity — against a locally hosted ERP, which is exactly the setup these projects treat as the difficult one.

The ERP vendor's CRM, or a separate system

"Everything from one supplier" is a procurement argument. It answers who sends the invoice, not whether your sales team can work in the result. Two other things decide the selection.

First, does the system carry the adjacent work? A tool that serves only sales leaves you shopping for a second one within two years to handle campaigns, website tracking and marketing — which is the fragmented landscape you were trying to avoid. Second, is the ERP connection documented and robust, or is it a project promise? Platforms such as HubSpot have an advantage here, because marketing, sales and service sit on the same records and the integration paths are published.

Our view: select on the scope of work beside sales and on the quality of the connection. The vendor logo tells you nothing about either.

Which system owns which data

Once both systems exist, the question of where each piece of information lives comes up quickly. In this constellation the answer is unglamorous. The ERP stays the leading system for material, pricing and order data (golden record). Technical quotes with line items and price calculation belong there.

The CRM does CRM work. It owns the relationship, the history, the ownership and the forecast. Rebuilding ERP quote calculation inside the CRM creates a double-maintenance burden that no team sustains for long.

We have worked through the full split by data type separately: CRM and ERP: Which Data Belongs Where. This article answers the question that comes before it — the one about sequence.

Where the failures actually happen

Integration gets treated as a technical risk. In practice the build is manageable, and what goes wrong is created earlier, around a table. The failures sit in the definition.

Four questions decide whether a handover holds. Which data points get exchanged at all? In which direction? How often? And who notices when something does not arrive? The fourth is the one most often skipped, and it is the one that costs trust later.

Frequency is a business decision too. Hourly synchronisation is harmless overnight and costs the sales team its patience during the day, when a record created minutes ago stays invisible in the other system for an hour.

When not to pull the CRM forward

The sequence is not an article of faith, and there are situations where it goes the other way. Three of them are visible early enough to decide cleanly.

The four situations at a glance

The table below summarises which situation calls for which sequence, and what you decide it on.