Questions to ask an enterprise platform implementation services vendor before you sign

Ask an enterprise platform implementation services vendor eight things: how they scope, how they migrate and reconcile data, how they handle interfaces with no API, how they cut over and roll back, who owns the code, what the support contract covers, who is on the team and for how long, and what their last failed programme taught them.

The purpose of these questions is not to catch anyone out. It is to separate vendors who have finished programmes like yours from vendors who have sold them. Below is each question, what a competent answer sounds like, and the specific warning sign that should make you keep looking.

What are you actually testing for?

Three things: whether the vendor has been present at a go-live, whether they will tell you something you do not want to hear, and whether their commercial structure survives contact with reality. Everything else, methodology decks, partner badges, team size, is downstream of those.

The tell is specificity. A vendor who has run these programmes answers with nouns: record counts, reconciliation reports, rollback rehearsals, named environments, hypercare durations. A vendor who has not answers with adjectives: robust, proven, agile, seamless. You can usually hear the difference within ten minutes of the first technical call.

We answer these questions in the same order on every enterprise platform implementation pursuit, and we would rather lose a deal on an honest answer about migration effort than win it and renegotiate in month four.

The eight questions, and how to read the answers

On scoping and estimating

Ask the vendor to show you a scope document from a previous programme, redacted. What you want to see is processes rather than features, an assumptions register, and a phase-one module list that somebody locked. Then ask what they do when you request a change in month three. The right answer is that it gets priced and dated; the wrong answer is that they will absorb it, because absorbed changes are paid for out of test time.

Ask how they arrived at the number. If the estimate came from a spreadsheet of requirements without a conversation about record counts and interfaces, it is a bet rather than an estimate. Our position on this is set out in what to put in an implementation RFP, which is the same discipline viewed from the buyer's side.

On data migration and reconciliation

The single most revealing question in this whole list is: which number will prove the migration worked, and who signs it off? A vendor who has done this will name one immediately, usually a closing balance, an open-order value or an active headcount, and will say that the reconciliation report gets written before the migration scripts do.

Follow up by asking what they do when reconciliation fails at 99.4 per cent. The competent answer involves an exception process, a named business decision-maker and a documented tolerance agreed in advance. The uncomfortable answer is that they have never had that happen.

On integrations, cutover and rollback

Ask them to walk through one interface from a past programme end to end: the format, the failure mode, the retry policy, how duplicates were prevented and how it was reconciled. One concrete story tells you more than a connector catalogue.

On cutover, ask when the rollback was last rehearsed rather than whether a rollback plan exists. Everyone has the plan. Far fewer have executed it in a test environment with real volumes and timed it. Ask what the rollback decision point is, in clock time, and who is authorised to call it at two in the morning.

On ownership, security and exit

Ask directly: at the end of this, who owns the source code, the configuration, the integration adapters, the documentation and the data, and what does it cost to leave? Our answer is that you own all of it, and we say so before contract rather than in a schedule. The code and IP ownership entry in our glossary sets out what that covers.

On security, ask which standard they build and test against rather than whether they are secure. A vendor that names a specific framework, such as the OWASP Application Security Verification Standard, which publishes testable security requirements for application development, is describing a process. A vendor that answers with a certification logo is describing a purchase.

On support, SLAs and escalation

Ask for the numbers: hours of cover, response target, resolution target, monthly change hours, and what happens during month-end on a Sunday. Then ask who is on call and whether that person worked on your build. Continuity from build into support is worth more than an aggressive response time answered by somebody reading the documentation for the first time.

Our Care Plans give a reference scale: Essential at $1,000 or ₹68,000 per month with business-hours IST cover and an eight-hour response, Standard at $2,500 or ₹1,60,000 with 24x5 cover and a four-hour response, and Enterprise at $5,250 or ₹3,40,000 with 24x7 cover, a one-hour response and a named engineer. Why response and resolution are different promises is explained in SLAs that mean something, and the inclusions are on the maintenance and support page.

Questions about money worth asking bluntly

• What is not in this price? The answer should be a list, not a reassurance.
• What is your change-request day rate? Agree it at tender, not during an incident.
• How do payment milestones work? They should attach to measurements, not to calendar dates.
• What do licences and environments cost at year three? Seat counts rarely shrink.
• How many weeks of parallel running have you assumed, and who staffs the double entry?
• What does hypercare cost and how long does it last? If it is free, it is short.
• If we stop after phase one, what do we have? A phase that leaves nothing usable is not a phase.

Published starting prices for our programmes are on the pricing page: implementation from $28,000 or ₹18,40,000 to $140,000 or ₹1 crore, and support from $1,000 or ₹68,000 per month.

Ask the referee, not the vendor

Request two references: one programme that went well and one that went badly. Ask the referee what moved, who paid for it, whether the team that started finished, how long hypercare actually lasted, and whether they would let the same vendor run the next phase. Referees answer that last question honestly more often than you would expect.

A vendor who cannot produce a reference for a difficult programme has either not run one or does not have a relationship that survived it. Both are useful to know. Signs your vendor is out of their depth covers the patterns that show up once delivery has started.

When this list is the wrong tool

If the engagement is small, two processes, four modern interfaces and a two-year data history, running a full due-diligence interview is disproportionate. Ask about scope, ownership and support, sign a short contract, and spend the saved effort on getting your process owners available. Due diligence should scale with blast radius.

There is also a version of this that goes wrong. A buyer who uses the list as a compliance exercise, collecting written answers without follow-up questions, will get eight well-drafted paragraphs and learn nothing. The value is entirely in the follow-up: ask for the specific programme, the specific number, the specific night. If you would rather talk it through than write it down, contact us and we will answer these in the order above.

Related reading

Five ways these projects fail explains what the answers above are protecting you against, the hidden costs quotes leave out lists what to make a bidder price explicitly, and the university ERP modernisation case study shows what these answers look like when they are true.

You are not buying a platform from an implementation vendor; you are buying their behaviour at two in the morning during cutover, and these eight questions are the cheapest way to find out what that behaviour will be.