Insights / Guide / Enterprise software implementation
GuideEnterprise software implementation: the complete guide
Most enterprise software projects fail on process and adoption, not technology. How to choose a platform, run fit-gap, migrate data and go live with confidence.
An enterprise system, whether for finance, sales, stock, projects or all of them together, promises one version of the truth: fewer spreadsheets, fewer re-keyed entries and live reports for the people running the business. Many organisations get there. Many others end up with a system that cost more than planned, went live late and is used in ways that recreate the old problems, with spreadsheets reappearing around the edges within months.
The difference rarely lies in the software. Most enterprise software projects fail on process and adoption, not technology. This guide brings together the briefings in our implementation series and walks through the stages that decide the outcome: choosing the platform, fit-gap analysis, customisation, data migration, contracts, go-live and the years that follow.
Choose software for the business you will become
Selection is the first big decision, and it is easy to get wrong in either direction. A system chosen only for today can limit growth when you add a new entity, currency or sales channel. A system chosen for an imagined future can overcomplicate today, with costs and screens nobody needs yet.
- Plan for two to three years. Consider new entities, markets and channels that are likely, not just possible.
- Prefer modular growth. Choose platforms that let you add capability when you need it rather than paying for everything up front.
- Check the ecosystem. The availability of skilled people, implementation partners and ready-made integrations affects long-term cost as much as the licence.
- Compare total cost of ownership over five years, not just the first-year price.
- Watch for bias. If an adviser resells one product, ask how they would answer if that product were not on the list.
Score shortlisted platforms against your most important processes using scripted demonstrations: give each vendor the same real scenarios, such as a multi-currency invoice or a partial delivery, and watch them run through them. Polished general demonstrations tell you little about how the software handles your particular business.
Fit-gap: the phase that decides the budget
Fit-gap analysis is where you compare how your business should work with what the standard software does, and decide what to do about every difference. It is the most valuable phase of any implementation and the one most often rushed. Skipping it is the most common cause of overruns, because gaps found during testing or after go-live are far more expensive to resolve.
- Design the process before the system. Map how work should flow in future, not just how it flows today.
- List processes by importance. Start with those that earn or protect the most money, and test the software against them first.
- Classify every gap as fit, configure, adapt the process, customise or leave out.
- Agree the decisions in writing, recording who accepted each gap and why, so later debates start from facts rather than memory.
Adapt the process first
Standard software usually reflects common good practice. Before customising to match how you work today, ask whether changing the process would be cheaper and just as good. Often it is.
The true cost of customisation
Every custom feature must be tested, documented, supported and carried through every future upgrade. The initial build is only the start. A customisation that took two weeks to build may cost several more weeks across its life, each time the platform releases a new version and the change has to be checked and often reworked.
That does not mean never customise. Where a process genuinely sets you apart from competitors, or where regulation requires something the product cannot do, custom work can earn its keep. The discipline is to customise only where it creates clear value, and to know the lifetime cost when you decide.
- Count the lifetime cost: build, testing, documentation, support and upgrade work.
- Prefer configuration. Settings and standard options cost far less to carry than code.
- Keep customisations small, isolated and documented, so upgrades remain straightforward.
- Review the list of customisations every year and retire those that no longer earn their place.
Move your data cleanly
Poor data shows up on day one. Duplicate customers, inconsistent item codes and missing opening balances surface the moment people start using the new system, and they damage trust faster than any software fault. Data quality can sink a project, yet cleansing is often left until the final weeks.
- Decide what to move: current balances, open orders and invoices, and active master records. Archive history you rarely use.
- Name an owner for each data set, such as customers, suppliers, items and the chart of accounts.
- Clean at the source: merge duplicates, fix formats and fill missing fields before loading, not after.
- Map old fields to new ones and agree how to handle anything that does not fit.
- Run at least two mock migrations and reconcile the results against the old system.
- Rehearse the cut-over until the timing and steps are predictable.
- Get business sign-off on the reconciled figures before go-live.
Questions to ask before you sign
The contract shapes everything that follows, so treat it as the start of a working relationship rather than a purchase. A good partner will answer these questions plainly. If answers are vague now, delivery will be vaguer.
About fit
Which of our processes will the standard product support without change? What must be configured, and what must be custom built? Who owns the fit-gap analysis, and will we see it before the contract is final?
About cost
What is included in the quote, and what is not? How are changes priced? What are the licence, hosting, support and upgrade costs in years two to five? If the project takes longer than planned, who bears the cost?
About delivery
Who will actually work on our project, and what is their experience in our industry? How will our data be cleaned and migrated, and how many rehearsals are planned? What does training look like by role? How will success be measured after go-live?
About the exit
Can we export our data in a standard format? Who owns the customisations? What are the notice periods and fees to end support? Ask for references from similar organisations and speak to them directly, without the vendor on the call.
Go live, then keep improving
Compliance is local. Tax rules, electronic invoicing and statutory reporting differ by country, and each market you operate in needs its own plan from the start. Leaving them until late testing is a frequent cause of delayed go-lives, especially for groups with entities in several jurisdictions.
Adoption decides the return. A system people avoid delivers nothing. Involve users in design, train by role with real scenarios and measure use after go-live. Plan a period of hypercare, typically several weeks, in which the project team stays close to users, fixes issues quickly and watches for workarounds.
The system was ready on time. What saved the first month was that the team stayed on the floor with us for three weeks after launch, fixing things the same day.
Finance director, manufacturing client
After hypercare, the work continues. Schedule regular health checks, plan upgrades rather than deferring them and keep a list of enhancements requested by users. Clean data and connected workflows also prepare the ground for reporting and AI tools later, which can only be as good as the data and processes beneath them.
Done well, an implementation gives you one version of the truth across finance, sales, stock and projects, faster and cleaner operations, live reports for managers, compliance built into the process and a platform ready for what comes next. If you are planning a project, start by listing your five most valuable processes and writing a scripted scenario for each; use them both to compare platforms and as the backbone of your fit-gap analysis.
Source: Intelliversal analysis, drawing on the briefings in this series.
