How long does custom enterprise software development take? A realistic timeline
How long does custom enterprise software development take?
Most custom enterprise software development reaches a first production release in eight to sixteen weeks after a two-to-three-week discovery. Multi-module programmes with heavy integration and a phased rollout run six to nine months. Integration count and data quality drive the calendar.
Most custom enterprise software development reaches a first production release eight to sixteen weeks after a discovery of two to three weeks. Multi-module programmes with several integrations, a data migration and a phased regional rollout run six to nine months end to end. Integration count and data quality drive the calendar far more than feature count does.
Below is a week-by-week calendar for a typical sixteen-week programme, the stages that genuinely overlap, the eight things that reliably add weeks, and the point at which a supplier who commits to a date is guessing. Eazyware prices and programme durations are used throughout so the figures are checkable.
Why the honest answer is a range
Two programmes with identical feature lists can differ by four months. The variables are not in the requirements document.
The first is the integration count. Each interface to an existing system carries a contract to agree, an owner to find, a test environment that may not exist, and a third party who has their own release calendar. Two interfaces is a fortnight of coordination; eight is a workstream with a lead.
The second is data quality. Migration timelines are set by how many records fail validation on the first trial load, which nobody knows until the load runs. A clean extract moves in days. An extract with duplicate customers, missing tax identifiers and three spellings of the same city takes weeks of cleansing that your team, not the supplier, usually has to do.
The third is decision latency on your side. A programme where acceptance decisions take a week rather than a day loses roughly a day per sprint, which compounds. This is the single most controllable variable in the whole schedule, and it costs nothing to fix.
A fourth variable deserves a mention because it is invisible in plans: the number of people who can say no. A programme with one accountable owner moves at the pace of the build. A programme where four directorates each hold a veto moves at the pace of their shared calendar, and no amount of engineering capacity changes that.
How long does each stage take?
Elapsed weeks, not effort weeks. Several of these overlap, which the third column makes explicit.
| Stage | Elapsed time | Overlaps with | What stalls it |
|---|---|---|---|
| Discovery and scope lock | Ten days to three weeks | Nothing; it gates the rest | Process owners who cannot get released from day jobs |
| Architecture and interface contracts | One to two weeks | Late discovery | A third-party system owner who will not commit to a payload |
| First vertical slice to staging | Weeks three to six | Migration analysis | Missing test environment or credentials |
| Core build | Six to fourteen weeks | Migration trials, security review | Slow acceptance decisions and mid-build scope changes |
| Data migration trials | From week three, three to six cycles | Build | Source data quality; each failed load costs a cycle |
| Security and compliance review | Two to four weeks | Late build if booked early | Being booked after the build instead of during it |
| User acceptance and training | Two to four weeks | Nothing; needs a stable build | No named acceptance owner per function |
| Cutover and hypercare | One to four weeks per phase | Next phase build | A rollback plan that has never been rehearsed |
A sixteen-week calendar, week by week
Weeks zero to three: discovery and contracts
Process maps, a domain glossary, a ranked scope list and an integration inventory. By the end of week three every interface has a named owner on both sides and a written payload. If that is not true, the date you are about to commit to is fiction. Scope is locked here, which is the discipline described in scope lock.
Weeks four to six: first slice in staging
One complete journey works end to end: sign-in, the core transaction, the write to the system of record, the audit entry. It is deliberately narrow. Its purpose is to prove the architecture and to give your users something real to react to while changes are still cheap. Migration analysis starts in parallel and the first trial load runs by week six.
Weeks seven to twelve: core build and migration cycles
Functionality widens sprint by sprint, each with acceptance criteria agreed before the sprint starts. Migration runs its second and third trial loads with reconciliation reports that finance signs, not engineering. The security review is booked during this window rather than after it, which is the single most common cause of an avoidable four-week delay.
Weeks thirteen to sixteen: acceptance, cutover, hypercare
User acceptance against scripted scenarios, training delivered to the people who will actually use the system, a rehearsed cutover, and two to four weeks of hypercare with a defect burn-down. Then the system moves onto a support contract rather than staying with the build team indefinitely.
Eight things that add weeks
- An integration whose owner is a vendor. Their change window, not yours, sets the date. Ask for it in week one.
- Source data nobody has profiled. Run a profiling pass during discovery; a bad first trial load costs a full cycle.
- A security review booked at the end. Formal verification against a standard such as the OWASP Application Security Verification Standard is a defined body of work with levels and requirements, so schedule it as work rather than as a signature.
- No named acceptance owner. Decisions queue behind a committee that meets fortnightly and the whole schedule inherits that cadence.
- Mid-build scope additions. Each one is a trade, not an addition. Write down what comes out.
- Environments that do not exist yet. Non-production copies of the systems you integrate with take longer to provision than anyone expects.
- Statutory or seasonal freeze windows. Year end, audit season, an academic term or peak retail trading will move your go-live whatever the plan says.
- Training delivered too late. If users first see the system in the acceptance window, acceptance becomes a second requirements exercise.
Two of those deserve a number. A vendor-owned interface typically adds two to four weeks of elapsed time purely in coordination, even when the work itself is a day. An unprofiled migration adds one full cycle, usually two to three weeks, for every trial load that fails validation badly enough to need a mapping change.
What can genuinely run in parallel, and what cannot
Data migration analysis, security review preparation, training material and infrastructure provisioning all overlap the build cleanly, because they depend on the architecture rather than on finished features. Running them in series is the most common self-inflicted delay in enterprise programmes.
What cannot overlap: user acceptance needs a stable build, cutover needs completed acceptance, and scope lock has to precede architecture. Compressing those boundaries does not save time; it moves the defect discovery into hypercare, where it costs several times more. Where a programme has multiple modules, phase the go-lives instead, as set out in phased ERP delivery and in the phased go-live definition.
What it costs to buy certainty about the date
A ten-day Sprint Zero through the AI discovery sprint at $3,250 or ₹2,00,000, credited against the build, converts a guessed date into a scoped one. A three-week ProofRun at $6,250 or ₹4,00,000 proves the riskiest interface before the main build is committed. Full custom and enterprise software development starts at $24,500 or ₹16,00,000 and runs to $175,000 or about ₹1.2 crore for multi-module platforms; all starting prices are published on the pricing page.
After go-live, hypercare hands over to a Care Plan: Essential at $1,000 or ₹68,000 a month with an eight-hour response in business hours IST, Standard at $2,500 or ₹1,60,000 with 24x5 cover and a four-hour response, Enterprise at $5,250 or ₹3,40,000 with 24x7 cover, a one-hour response and a named engineer. Putting that transition in the plan stops the build team from becoming an unpriced support desk.
Parallel running is the other schedule tool worth budgeting for. Keeping the incumbent system live alongside the new one for a full business cycle costs duplicated data entry or a synchronisation feed, and it is the difference between a reversible go-live and a one-way door. Put those weeks in the plan explicitly rather than hoping the cutover goes cleanly enough not to need them.
When a date cannot honestly be committed
There are cases where any supplier quoting a fixed date is guessing. When the source data has never been profiled and the migration is the critical path, the honest answer is a date for the trial load and a date for the date. When a regulator or auditor has to approve the change, their calendar governs. When the business process itself is still being argued about between departments, no schedule survives, because requirements will keep moving under the build.
In all three cases the right move is a smaller, paid, time-boxed piece of work that removes the unknown, then a committed date for the rest. A fixed-price commitment on an unprofiled migration is how both sides end up in a change-request argument in month four.
What this looked like in practice
A university ERP modernisation had a constraint most enterprise programmes do not: an academic calendar with no quiet week, where admissions, fees and examinations each own a part of the year. The schedule was built backwards from those windows rather than forwards from kick-off, with modules going live in the gaps and the incumbent system running in parallel throughout. The programme is described in the university ERP modernisation case study, and the phase-by-phase mechanics are in our practical implementation guide.
Related reading
Five ways custom enterprise software projects fail covers the schedule risks in more detail, and what to put in an RFP shows how to ask bidders for a timeline you can compare rather than a number you cannot.
Commit to the date only after the integrations have owners and the first trial load has run; everything before that is an estimate wearing a deadline's clothes.
Frequently asked questions
Can custom enterprise software be delivered in under three months?
▾
Yes, for a single module with two or three integrations and clean source data. Eazyware ships a first production slice in eight to sixteen weeks for most scoped builds. What does not compress is discovery, user acceptance and cutover rehearsal, so the saving comes from narrower scope rather than faster work.
What is the longest part of an enterprise software project?
▾
Usually data migration, because its duration is set by source data quality, which is unknown until the first trial load runs. Three to six reconciliation cycles is normal. Integration coordination with third-party vendors comes second, since their release windows govern rather than yours.
How do we stop our own side from delaying the project?
▾
Name one acceptance owner per function with authority to sign off, agree a 48-hour decision turnaround in the contract, release process owners for discovery properly rather than partly, and give the migration team production-shaped data in week one instead of week six.