ERP Integrator: Role, Selection, Budget and Project Timeline, Seen Through Your Data

The tender is out, three proposals have come in. Each one details configuration, custom development, training and acceptance testing. In one of them, a shorter line: “Data migration: client’s responsibility.” No one picks up on it in committee. It comes back during acceptance testing, when the first loaded files reveal duplicate items and customers without payment terms.

Choosing an ERP integrator means choosing who will deliver the software. It also means deciding, often without saying so, who will own your data: extracting it from the old tools, cleaning it, having it validated, connecting it to the CRM. This guide covers the four questions people ask before signing — role, selection, budget, timeline — and, for each one, looks at what happens to the data.

What an ERP integrator does

An ERP integrator is the provider that implements the chosen software: it translates your processes into configuration, develops what the standard product does not cover and supports go-live. It knows the vendor. It does not know your data until it has seen it.

Configure, develop, train, support go-live

The core of the job is configuration: chart of accounts, purchasing and sales workflows, stock rules, user rights. Then comes custom development, when a process does not fit the standard product, followed by key-user training and go-live support. A good proposal describes each workstream with its deliverables and assumptions.

What stays with you

Some responsibilities cannot be delegated. Business decisions: which approval workflow for a purchase, which discount rule. Data validation: only a buyer knows whether a supplier record is correct, only management control knows whether a balance is accurate. And finally acceptance testing, which checks that the ERP does what your teams expect, on your real cases.

The area in between

Between these two scopes lies an area that belongs to no one: data migration, cleaning, item and customer master data, interfaces. The integrator knows how to load a file; it does not know which customer record is the right one among three. Your teams know; they do not know how to produce the file in the expected format, or how to check it after loading.

Whatever is written nowhere in the proposal ends up being done by someone who did not have the time to do it.

Data, where ERP projects go off track

A configuration can be fixed with a few settings. Wrong data loaded into the ERP spreads: into an order, an invoice, an accounting entry. That is why real files need to be loaded early in the project.

Migrating data: extract, transform, load, check

Data migration breaks down into four steps. Extract the data from the old tools, often more than one: a former ERP, a sales management tool, Excel files. Transform, that is, apply the mapping rules: an item family that becomes two, a payment term that changes code. Load into the ERP. Finally, check, by comparing what arrived with what left: number of records, totals, balances.

The check is the only step that tells you whether the migration is right: it must be planned from the start. With several sources, another question arises: which one is the system of record for each object. At Orhatek, the migration from Sellsy to HubSpot, connected to Pennylane, covered contacts, companies, suppliers and the product catalog; it was not an ERP, but the question was the same.

Item and customer master data

Master data is the reference list for an object: items, customers, suppliers. An item created twice skews stock, a customer present under three names skews outstanding balances. The ERP project is the time to decide that there is only one record per customer and per item, and to write the creation rules: who creates, with which required fields. If your current tools already contain duplicates, our article on fixing duplicates in a CRM or an ERP details the method.

Interfaces with the CRM and business tools

An ERP exchanges data with the CRM, the support tool, logistics. For each interface, three decisions: the direction of exchanges, the frequency, and what happens when an exchange fails. These decisions are detailed in our guide on integration between ERP and CRM.

The case of Focal shows the cost of a missing interface. The high-fidelity audio systems manufacturer managed its after-sales service in Freshdesk, with no connection to its Infor LN ERP: every customer request was entered twice. On top of that, there were two separate instances, one for France and one for Canada. The project connected Freshdesk and Infor LN across the entire request-handling process, merged the two instances and migrated the North American data with its history, without interrupting service. Duplicate data entry disappeared with this interconnection.

To find out which data workstreams already have an owner in your project, and which have none, the diagnostic at the top of this article takes four questions.

Choosing an ERP integrator

For the same vendor, proposals look alike on configuration. They differ on what they say, or leave unsaid, about your data.

What its proposal must say about your data

A serious proposal names the data workstreams: which objects, from which sources, with how much history. It states the number of trial migrations before the final migration, who cleans, who validates each file and on what criteria. It describes the interfaces with their direction and frequency. When these lines are missing, the proposal is not cheaper: it has shifted part of the work onto you.

Questions to ask at the pitch

• Which dataset it worked on. A standard demo shows the software; a demo on an extract of your items and customers shows what lies ahead.
• Who, on its side, owns the migration. A name, a role, time allocated. A migration entrusted “to the project team” with no designated owner has no owner.
• What happens if the data is not ready. Postponed cutover, go-live with a reduced scope, contract amendment: the answer tells you how the risk is shared.

Warning signs

Three phrasings should set off alarm bells. A migration that is the “client’s responsibility” with no support: the clause is not unusual, but it assumes you have the skills and the time to deliver it. A single migration planned just before go-live, with no margin to correct. A demo done without your data. For an Odoo project, our guide on choosing an Odoo partner complements these points. Finally, ask what will be handed over to you: documentation, transformation rules, access. That is what limits dependency on the provider.

Budget: what drives the bill

The price of an ERP project depends on items missing from some proposals, and above all on the volume and condition of the data to be migrated.

The line items of an ERP project

• Licenses. Billed by the vendor or resold, they are separate from the integrator’s work.
• Configuration and custom development. They follow the number of processes covered.
• Data migration. It depends on the number of sources, the volume and the condition of the data.
• Interfaces. Each connection to another tool adds rules to write and test.
• Training and post-go-live support. It is an easy line to cut, and a hard one to rebuild later.

Migrate less to spend less

Every piece of migrated data is extracted, transformed, loaded and checked at each trial migration: so you need to sort before pricing. Master data and open balances — open orders, stock, customer and supplier balances — are migrated, after cleaning. History does not always need to be migrated line by line: a balance or a summary may be enough in the ERP, and the detail remains available in the old tool or an archive. This sorting is decided with the business teams, not just with the integrator.

Fixed price or time and materials

The billing model allocates the risk of overrun: on time and materials, you buy days and you carry that risk; on a fixed price, the provider commits to a result and carries it for you. For an example budget on a specific vendor, see the budget for an Odoo project.

How an ERP project unfolds

The stages are well known. What separates a project that stays on track from one that slips is the data deliverable expected at each of them.

Scoping and design

This is where the data dictionary is decided: the objects migrated, their fields, their source, their owner, and the transformation rules. A scoping phase that only produces target processes pushes data back to later, when it costs the most.

Configuration and trial migrations

During configuration, the trial migrations begin: a full load into a test environment, a check, corrections, a new migration. Each run reduces anomalies and measures the actual time the migration takes, which is useful for planning the cutover. Plan several: a single trial migration leaves no margin for correction.

Acceptance testing, cutover and first weeks

Acceptance testing is done on real migrated data, not on a demo dataset: it is the only way to check that an invoice comes out right for a real customer. The cutover chains together stopping data entry in the old tool, the final migration, the checks and go-live. To preserve business continuity, it is written as a procedure, with a defined rollback point. During the first weeks, every data correction must have an owner.

Adoption

A correct ERP that is poorly used becomes wrong again: records get created twice, workarounds return. Adoption is prepared during the project, with the entry rules and the people who enforce them. Our guide on change management details this stage.

A successful cutover is one more trial migration, done for real.

Where to start

Before comparing proposals, do a short assessment of your data: the tools that contain customers, items or suppliers, the visible duplicates, the fields with no owner, the history that is actually useful. This work makes the proposals comparable and lets you write into the tender who will own each workstream. That is the work we do at turnK, upstream of or alongside the integrator you have chosen: making the data reliable so that the ERP goes live on a sound foundation.