All services Every engagement has a fixed, published price. Book a strategy call
The architecture questions to ask ERP vendors before you sign. Data model, integration, licensing, upgrades and exit, with a table of what good answers look like.
An ERP contract is one of the longest commitments a company signs. The subscription runs for years, the implementation costs a multiple of the licence fee, and the data model quietly shapes how the business reports, prices and plans for a decade. Most selection processes still spend nearly all of their effort comparing features and negotiating price. The differences that decide whether the programme succeeds sit in the architecture, and they are cheapest to fix before anything is signed.
This guide sets out the architecture questions to ask before you sign, with a table of what good answers look like, the subjects vendors tend to avoid, and a simple way to run the architecture work alongside the commercial negotiation. It is written for UK boards, CFOs and CIOs choosing or replacing an ERP. Intelance does not resell software and takes no commission from any vendor, so the guidance is independent.
The short answer. Before you sign an ERP contract, get written answers on eight things: how the data model fits your business, how complete and well documented the APIs are, what can be changed by configuration without code, how upgrades work and who carries the testing, where the system is hosted and how it recovers, how the licence counts users and indirect access, how you get your data out for reporting and AI, and what exit looks like. Put the answers in the contract schedules. Have someone independent of the vendor and the implementation partner check them.
Everything you ask for before signature is negotiable. Almost nothing is afterwards. Once the contract is signed, every gap you find becomes a change request priced by the vendor and every assumption becomes your risk. That is the whole argument for doing the architecture work early, and it is an argument about money rather than technology.
The second reason is that feature comparison no longer separates the platforms. The major ERP products have converged on functionality. What still separates them is the shape of the data model, the quality of the APIs, the upgrade regime and the licence mechanics. Those are architecture questions, and they rarely appear in an RFP written by procurement alone.
The third reason is that the people selling the system will not raise these subjects for you. A demo is designed to show the platform at its best, on clean data, running the standard process. Your business will not run on clean data or the standard process. The questions below exist to close that gap while you can still walk away.
Ask every shortlisted vendor the same eight questions and insist on written answers. The table gives each area, what to ask in practice, and what a good answer looks like. A weak answer is useful information. An answer the vendor will not put in writing is a warning.
| Area | What to ask | What a good answer looks like |
|---|---|---|
| Data model | Ask for the entity model covering customers, products, sites, cost centres and the chart of accounts. Ask how many of your current structures map to it without workarounds. | The vendor runs a mapping workshop before contract and shows you where the fit breaks. Gaps are named in writing rather than discovered at migration. |
| Integration | Ask for the full API catalogue. Ask which entities have no API, what the rate limits are, and whether events are published when records change. | Documented, versioned APIs across every major entity, event streams for the records you integrate most, and no separate charge to reach your own data. |
| Configuration and customisation | Ask what can be changed through supported settings, what needs code, and what happens to that code at every upgrade. | A clear extension framework. Custom code sits outside the core and survives upgrades. The vendor can state the limits precisely. |
| Upgrades | Ask how often releases land, whether they can be deferred, how much regression testing each one forces on customers, and who pays for that testing. | A published release calendar, a sandbox refreshed before each release, and a testing burden your team can carry. |
| Hosting and resilience | Ask whether the platform is single tenant or shared, where UK data sits, who the subprocessors are, and what the recovery point and recovery time objectives are. | UK or EU residency in writing, named subprocessors, and recovery targets backed by service credits rather than intentions. |
| Licensing mechanics | Ask what counts as a user, how indirect access through integrations and portals is charged, where module boundaries sit, and what protects your price at renewal. | A worked example priced on your real usage pattern, indirect access answered in writing, and a renewal cap in the contract. |
| Reporting and AI readiness | Ask how you get data out at scale, whether warehouse access is included, and what data the AI features use and where it goes. | Bulk extract or direct warehouse access included in the price, a documented semantic layer, and AI features that can be switched off per module. |
| Exit and portability | Ask what you receive at exit, in what format, at what cost, and what help the vendor is obliged to provide. | A defined export of full data in an open format, exit assistance written into the contract, and no fee that punishes leaving. |
Five subjects almost never appear in a proposal unless the buyer raises them. Each one has ended up costing real UK businesses more than the original licence.
Selections go wrong when the architecture review happens after the decision has in effect been made. Run the two tracks in parallel from the first week. For most mid sized UK companies the whole process fits in ten to twelve weeks.
| Weeks | Commercial track | Architecture track |
|---|---|---|
| 1 to 2 | Longlist, budget and requirements | Document the entity model, the integration inventory and the reporting needs the new system must serve |
| 3 to 6 | Demos and shortlist | Scripted architecture scenarios in every demo, run by your architect rather than the vendor |
| 7 to 8 | Reference calls and pricing | Reference calls with architects at customers of your size and industry, asking what they would do differently |
| 9 to 10 | Contract negotiation | Every architecture answer moved into the contract schedules before signature |
The UK market prices ERP and architecture skills plainly. Independent contract architects charge £600 to £900 a day and large firm teams start from £1,500 a day for each consultant, as set out in our guide to enterprise architecture consulting costs in the UK. A selection mistake rarely shows up at go live. It shows up at data migration, at the first year end close and at the first forced upgrade, when the customisations built to paper over a poor fit all need retesting at once. By that point the annual cost of the workarounds is usually larger than the cost of the entire selection exercise done properly.
If you are unsure whether the organisation needs architecture capability at all for a programme of this size, our sizing guide gives an honest answer by company size and change load.
The vendor wants the deal and the implementation partner wants the build. Neither is placed to tell you the fit is wrong. An independent architecture review before signature is the one check in the process with no stake in the outcome.
Intelance advises on ERP and cloud transformation architecture as an independent practice. We do not resell software and we take no implementation revenue from vendors. An EA QuickScan baselines your architecture, data and integration landscape before the business case, from £18,000 + VAT, in ten working days. For programmes already in flight, ProjectEA embeds senior architects through selection and delivery from £45,000 + VAT. Every fee is agreed in writing before work starts.
Before the shortlist is set and again before the contract is signed. The answers should shape which vendors make the shortlist. After signature your negotiating position is gone and every gap becomes a change request priced by the vendor.
Configuration changes behaviour through settings the vendor supports, so it survives upgrades. Customisation changes behaviour through code, and every line of it must be retested each time the platform changes. Selection should establish exactly where the configuration limits sit for your processes.
Indirect access is the charge some vendors make when people or systems reach ERP data through an integration or a portal instead of a named login. It has produced some of the largest surprise licence claims in the industry. Ask for the policy in writing and price your integration pattern against it before you sign.
Yes. Answers given in demos and RFP responses carry little force unless they appear in the contract or its schedules. Move recovery targets, API commitments, data residency, renewal caps and exit assistance into the written agreement before signature.
For most mid sized UK companies a disciplined selection takes ten to twelve weeks from longlist to contract. Selections that run much longer usually lack a decision structure rather than information. Selections that run much shorter usually skip the architecture track.
The smaller the company, the less room there is to absorb a wrong choice. A short independent review before signature costs a fraction of one month of a struggling implementation. It does not need to be long. It needs to be independent of the vendor and the implementation partner.
Emmanuel Olatunji
Chief Enterprise Architecture Partner
Emmanuel founded Intelance in 2017 and has led architecture, AI governance, cyber and deal engagements across the UK, Europe, the Middle East and Africa. Every Intelance engagement runs under his direction, and every guide he publishes comes from that work.
See his record on LinkedIn About IntelanceThirty minutes with the architect who wrote this guide. A clear recommendation and a fixed fee in writing, within one UK business day.
Talk to a senior adviser
Enterprise Architecture
