Migrating billing platforms is one of the highest-stakes projects a finance or RevOps team will ever run. It touches every invoice you will send from that point forward, and getting it wrong means re-billing customers, restating revenue, or both. The questions below separate partners who have done this from partners who have read about it — and none of them appear on a standard RFP.
Ask how they handle in-flight subscriptions
Every migration has to deal with contracts that are live and mid-cycle at cutover, and this is where general assurances get expensive. Ask for a mechanical answer on each of the following, and listen for whether they volunteer the cases you did not think to ask about.
- Partial periods at cutover — is the final period billed from the legacy system or the first from the new one, and how is that boundary proven?
- Existing credit balances, unapplied payments and open credit memos
- Unbilled usage recorded before cutover and rated after it
- Future-dated amendments already entered in the legacy system
- Amendment history — migrated, summarised, or abandoned, and what that does to your ability to support prior periods
The amendment-history answer is the tell. Migrating current state is comparatively straightforward. Deciding what happens to the history that supports your existing revenue positions is a judgement call with real consequences, and a partner who has done this before will raise it before you do.
Ask for a reconciliation plan, not a cutover date
A cutover date is a project artefact. A reconciliation plan is the thing that tells you whether the new system can be trusted, and it should exist in writing before build starts — not be assembled in the fortnight before go-live by whoever is least busy.
- Which control totals are reconciled before go-live — recurring contract value by product, open receivables, deferred revenue balance, unbilled balances, credit balances
- What tolerance is acceptable on each, and who agreed to it
- Whether there is a parallel run, for how many cycles, and against what criteria it is judged
- What the rollback plan is if reconciliation reveals a material difference after cutover
- Who signs off that the migration is complete, and against which of the above
Then ask specifically about the first bill run on the new platform: what is checked before invoices are released, who checks it, and what the abort criteria are. A partner who has lived through a bad first bill run will have a detailed answer. A partner who has not will describe a process.
Ask what happens after they leave
A migration partner should leave you with a system your own team can operate. That is not a cultural preference — a billing platform you cannot change without raising a purchase order becomes a platform you stop changing, and a platform you stop changing stops matching how you sell.
- What configuration documentation is produced, and is it a deliverable or a by-product?
- Who on your team is trained, on what, and when — before go-live or after it?
- Which decisions are recorded with their reasoning, not merely their outcome?
- What the support arrangement covers for the first two close cycles, and what extending it costs
Ask about the engagement model, not just the price
A fixed-price, fixed-scope migration is appealing right up until requirements shift — which they always do, because a migration is the first time in years that anyone reads the old configuration carefully, and reading it changes what you want. A partner locked into a single upfront quote has a structural incentive to argue that your discovery is a change request.
Flexible models — hourly, part-time, or staged phases with a re-scoping gate between them — handle that honestly. What you are buying is the ability to change direction when the data tells you to, without opening a contract negotiation in the middle of a close cycle.
The real evaluation criterion
Everything above reduces to a single question: can this partner describe, in mechanical detail, how they handled the specific edge cases your business has? Not billing in the abstract — your proration rules, your contract types, your usage model, your entity structure, your reconciliation requirements.
Ask them to walk you through a migration that went badly, and what they changed afterwards.
Specificity is the only real signal available here. A partner who cannot get specific about a failure has either not done enough of these to have one, or is not going to be candid about yours.