Pick the one closest to the conversation you keep having internally. Two more questions after this — then a straight reading, not a score.
Five situations account for most technology decisions senior teams bring us. Each one leads to a second question, then a third — and the third matters more than either of the first two.
1 · Our systems do not talk to each other
When data crosses between systems, what happens? A person re-keys it · A file moves overnight · It mostly works, but nobody is sure
2 · We cannot trust the numbers
Where do the numbers diverge? Between business units · Between systems · Nobody agrees on the definition
3 · We are outgrowing how we run today
What is actually growing? More entities and more consolidation · More locations doing the same thing · Volume on the same structure
4 · A compliance date is coming
How long until the date? Under three months · Three to twelve months · Longer, we are planning ahead
5 · Something failed and we are re-thinking
What broke? An implementation went sideways · A vendor stopped fitting · We lost a person who held it together
Then, on every path: who owns this once it is live?
This is the question that changes the answer more than any other. A named team, already in place · One person, informally · Not decided yet
The readings
Every path can end in “do not act yet.” These are the readings this tool returns, in full.
Hold — the first decision is not the platform
Decide who owns this before you decide what to buy.
A system is only as good as the team that owns it on day four hundred. If that team does not exist yet, choosing a platform now fixes the easy half of the problem and leaves the hard half to arrive later — usually during go-live.
This is the one case where we will ask you to pause even though we would be the ones delivering.
What we would do first — Define the owning role and its authority, then re-open the platform question with that person in the room. Usually a short piece of work, not a programme.
When to come back — When you can name the person accountable for how this performs a year after launch.
This is an integration decision, not a platform one
The boundary is the problem. Replacing the core moves it, it does not remove it.
When work crosses systems by hand or by overnight file, the failure is at the seam. A new core system creates a new seam in the same place, at several times the cost and the longest programme your organisation will run.
The honest sequence is to fix the boundary first. If the core is still wrong afterwards, that will be obvious — and you will have a much cheaper way to prove it.
What we would do first — Map where data actually crosses, then put an integration layer on the two or three crossings that hurt. Weeks, not quarters.
When we would say no — If your ledger is sound and your people trust the numbers, we would tell you not to buy a replacement from us. It rarely repays inside three years on those terms.
This is a governance decision wearing a software costume
No platform can settle what a number means.
When teams disagree on the definition rather than the value, the disagreement is organisational. A system will encode whichever definition you give it — including the confusion — and then make it much harder to change.
We would rather tell you this now than bill you for discovering it in month five.
What we would do first — Agree the definitions and who owns each one. Then the reporting layer is a small piece of work rather than a transformation.
When we would say no — If the real disagreement is between two directors about who owns the customer, no platform settles that. Buying one postpones it.
This is a genuine core decision
Consolidation is structural. This is the case where replacement usually earns its cost.
Multiple entities, multiple currencies, and a close that finance performs in a spreadsheet is the one pattern where a full cloud core repays. The complexity is in the structure, not at the edges, so the edges cannot fix it.
It is also the longest programme you will run, and the cost you can see — the licence — is the smallest of the three that matter.
What we would do first — Establish the entity and consolidation model before any platform is shortlisted. That answer eliminates most of the market before a vendor is called.
What we would show you honestly — Licence, integration and data migration, and a year of dual-running. We put all three in front of you before you choose, not after.
Meet the date on what you have
A platform migration is the most expensive way to file on time.
Under three months, the goal is compliance, not architecture. Bolting a deadline onto a replacement programme is how both get missed.
Do the minimum that satisfies the requirement on your current stack. Then decide the architecture question on its own merits, without a date holding it hostage.
What we would do first — Get you compliant on the current systems, then run the architecture decision separately and unhurried.
When we would say no — If a vendor is telling you that replacement is the only route to compliance before your date, that is a sales position, not an engineering one.
The next decision is about accountability, not product
A second implementation on the same terms usually fails the same way.
When a delivery goes sideways, the instinct is to change the platform. More often the gap was between the party who advised and the party who delivered — nobody owned the whole outcome.
Before choosing anything new, it is worth being precise about where the last one broke: the decision, the delivery, or the handover between them.
What we would do first — A short honest read of what actually failed. Then one accountable party across both the decision and the delivery, so the seam does not reappear.
When we would say no — If the platform was fine and the process was undefined, a new platform will encode the same confusion.
There is a real question here — but not enough to prescribe from a form
What you described has more than one plausible answer.
Three questions can locate a decision. They cannot see your entity structure, your close, or where the exceptions live — and those usually decide it.
We would rather say that than give you a confident answer this tool has not earned.
What we would do first — Thirty minutes to work through how you actually operate, then a written direction with the trade-off and the case against it kept in.
What you will not get — A recommendation shaped by what we would prefer to deliver.