How long does enterprise platform implementation take? A realistic timeline

A single module with clean data and two integrations goes live in eight to twelve weeks. A multi-module rollout with full history and five to eight integrations takes sixteen to twenty-eight weeks. Add a custom extension for the process the platform cannot model and the range moves to twenty-four to forty weeks.

What follows is the critical path rather than a Gantt chart: which workstreams genuinely run in parallel, which cannot start until something else finishes, the five things that reliably add weeks, and a twenty-week calendar you can hold a supplier to.

Why the range is so wide

Configuration is the predictable part. A consultant who knows the platform can configure objects, fields, workflows and permissions on a schedule, and that schedule rarely slips by much. The variance comes from everything around it.

Data is the first source of variance. Nobody knows how bad a twelve-year-old customer table is until it is profiled, and the difference between a four per cent duplicate rate and a twenty-two per cent duplicate rate is several weeks of cleansing plus a much slower reconciliation. This is why we will not quote a go-live date before the data profile exists.

Integration count is the third. Each connected system adds an authentication method, an error path, a retry policy and a person who has to answer questions about it, and the coordination cost grows faster than the build cost. Four integrations is a workstream; eight is a programme within the programme. When a supplier quotes the same duration for four and for eight, they are quoting build effort and ignoring the elapsed time that coordination consumes.

Availability is the second. An implementation needs decisions from process owners, sign-off from a security lead, and reconciliation from someone in finance or operations. Those people have day jobs. A programme with two-week decision latency will run months longer than the same programme with two-day latency, and no amount of supplier capacity fixes it. Microsoft's Success by Design guidance for Dynamics 365 makes the same point structurally: the implementation phases are gated by readiness reviews rather than by engineering throughput.

The critical path: what blocks what

Read the last column rather than the second. Almost every overrun we are called into is a blocker that nobody owned: credentials for a system whose administrator left, a security review that was never booked, or a reconciler who was assumed rather than allocated.

What reliably adds weeks

• Dirty source data. Duplicate customers and free-text status fields are the single largest schedule risk. Profiling in week one converts an unknown into a plan; the case is made in data migration for platform implementations.
• A system nobody owns. Every estate has one integration whose administrator has left. Finding the credentials takes longer than building the connector.
• Late reporting requirements. Leadership reports arrive in UAT, after configuration has frozen, and each one reopens a data model question.
• Security and procurement gates. Penetration tests, vendor security reviews and DPA negotiation are elapsed time you do not control. Book them in week one.
• Decision latency. Two-week turnarounds on configure-or-extend questions compound across dozens of requirements.
• Peak-season freezes. Retail will not cut over in the festive quarter; education will not cut over during admissions. Freezes are real and must sit in the plan.

What genuinely runs in parallel

Three pairs overlap safely. Configuration and integration build run together once entity ownership is fixed, because the integration contract depends on ownership rather than on the finished screens. Data cleansing runs alongside both from week two, since cleansing the source does not require the target to be ready. And training content can be drafted during UAT, provided the screens are frozen.

Two pairs do not. Migration rehearsals cannot start before mapping is stable, or you spend the rehearsals debugging the map rather than timing the run. And UAT cannot start before integrations are feature complete, because testing a process with a stubbed integration proves nothing about the process. Compressing either of these is how a twenty-week programme becomes a twenty-eight-week one.

A twenty-week calendar for a multi-module rollout

Weeks 1 to 2: discovery

Process map with volumes, integration inventory with named owners, data profile with duplicate and null rates, module sequence, and the reporting list. This is a ten-day Sprint Zero at $3,250 or ₹2,00,000, credited against the build. It ends with a signed system-of-record table.

Weeks 3 to 10: configuration and integration

Configuration proceeds module by module in the agreed sequence while integration contracts are built against the ownership model. Data cleansing runs alongside from week three. Security review and any penetration test are booked now, not later. The first migration rehearsal happens at week eight, deliberately early and expected to fail, because its job is to find the mapping gaps.

Weeks 11 to 14: rehearsal and UAT

Three to four more timed migration rehearsals, each reconciled by finance or operations. User acceptance testing runs against production-shaped data with the exception cases operations already know about, not the happy path. Training content is drafted from the frozen screens.

Weeks 15 to 18: training and dress rehearsal

Users are trained on the system they will actually see. The final rehearsal is timed to the minute so that the cutover window is a measured number, and the rollback is executed once rather than written once. The sequencing logic for module-by-module launches is in phased ERP delivery.

Weeks 19 to 20: cutover, then four weeks of hypercare

Go live by module or by site with parallel running for anything touching money. The switchover mechanics are covered in zero-downtime cutovers, and the month that follows has its own discipline, set out in hypercare. Hypercare is part of the programme, not an afterthought.

Cost against the calendar

Duration and price move together because both are driven by modules, integrations and data volume. Enterprise platform implementation runs from $28,000 or ₹18,40,000 for the eight-to-twelve-week single-module shape to $140,000 or roughly ₹1 crore for the twenty-four-to-forty-week shape with a custom extension, with published starting prices on the pricing page. After hypercare ends, ownership passes to a Care Plan: $1,000 or ₹68,000 a month on Essential with business-hours IST cover, $2,500 or ₹1,60,000 on Standard with 24x5 cover and four-hour response, or $5,250 or ₹3,40,000 on Enterprise with 24x7 cover and a named engineer.

When going faster is the wrong ambition

Compressing the calendar is almost always done by removing rehearsals, shortening UAT or skipping parallel running, and each of those converts schedule risk into go-live risk. A cutover that fails costs more days than the rehearsals you cut, and it spends credibility you will need for the next module.

If a date is genuinely immovable, a contract end, a regulatory deadline, a factory shutdown window, reduce scope rather than compress the path. One module live on time beats four modules live late, and the sequence can always continue afterwards. And if the only reason for the date is that a budget expires, say so out loud: spending a capital budget on a rushed go-live is how organisations end up paying twice. We would rather lose that scope than deliver a cutover we would not sign off ourselves.

A checklist to hold the date

• Source-system access granted and credentials verified before week one ends
• Data profile complete, with duplicate and null rates per entity, before any date is promised
• System-of-record table signed off, one owning system per entity
• Every integration has a named owner who answers within two working days
• Security review, penetration test and data processing agreement booked in week one
• The reconciler in finance or operations is allocated, with dates in their calendar
• Reporting list agreed and frozen before configuration starts
• Business freeze windows marked in the plan: festive peak, admissions, year end, audit
• Rollback executed once in rehearsal, not merely documented

What a real calendar looked like

A university modernising a fifteen-year-old ERP had cutover windows dictated by the academic calendar rather than by the programme plan: nothing could change during admissions, and nothing could change during examinations. The sequence was built backwards from those windows, with modules grouped to fit the gaps between them. The work is described in modernising a fifteen-year-old university ERP without a rewrite. Constraints like these are usually discoverable in week one, and almost always discovered in week twelve.

Related reading

Enterprise platform implementation services: a practical implementation guide covers the delivery sequence in detail, and what enterprise platform implementation services cost in 2026 covers the budget that goes with this calendar. If you want a date checked against your integration inventory, send it over.

Ask a supplier what blocks each workstream rather than how long it takes, and the answer will tell you whether their date is a plan or a wish.