Upgrade or re-implementation: how to tell which one you have been quoted
Last reviewed: 15 September 2026
- →An upgrade changes the software under your configuration. A re-implementation rebuilds the configuration.
- →Boards scrutinise the two differently, which is why the label gets stretched.
- →Five questions, asked in writing, settle it before the scoping call.
- →The vendor's own upgrade notes usually tell you first.
- →Price both paths in the same paper, with rebuild work in both columns.
An upgrade changes the software underneath your configuration. A re-implementation rebuilds the configuration itself. If the scope of work includes rebuilding your reports, page templates, automated processes and integrations, you have been quoted a re-implementation. The word on the cover page does not change what is inside it.
Why the label matters more than it should
Boards treat the two differently, and correctly so.
An upgrade is maintenance. It goes through as an operational line item on the recommendation of whoever manages the system. Nobody asks for options. Nobody tests the price.
A replacement is a project. It needs a business case, a comparison, sometimes a tender, and a paper that survives a sceptical director asking what else was considered.
The five questions
Put these to whoever wrote the quote, in writing, and keep the answers.
- Which of our existing reports and saved queries will run unchanged?
- Which integrations need to be rebuilt or repointed, and who pays for that work?
- Which of our customisations are supported in the new version, and which have to be redone?
- Does our member-facing website come across as it is, or is it rebuilt?
- What retraining do staff need before go live?
If four of the five answers involve rebuilding something, you are not upgrading.
| Upgrade | Re-implementation | |
|---|---|---|
| Reports and queries | Run unchanged | Rebuilt and revalidated |
| Integrations | Keep working | Repointed or rewritten |
| Customisations | Carried forward | Reassessed one by one |
| Member-facing pages | Unchanged | Rebuilt on new templates |
| Staff | Notice a new look | Need retraining before go live |
| Approval needed | Operational | Board decision, with options |
The documentation usually tells you before the quote does
Platform vendors publish upgrade notes, and those notes are more candid than any sales conversation. Find the breaking changes page for the version you are being moved to and read it before the scoping call.
The things that commonly sit in those documents: third-party payment gateways withdrawn in favour of the vendor's own processor, database functions renamed so existing integrations stop working, older member site templates removed from the product entirely.
None of that is a scandal. It is ordinary platform evolution and every vendor does it, including this one. But each line is something you will pay a consultant to rebuild, and it is published months before anybody quotes you for it.
The thing you are protecting is usually the thing that goes
The strongest argument for staying put is the investment already made in configuration. Years of queries, rules, templates and process, tuned to how your organisation actually works.
Read the scope of work again. If that configuration is being rebuilt either way, it is not an asset on one side of the decision. It is a cost on both sides. What you are genuinely keeping is the data model and the supplier relationship. Both have real value. Neither is the thing most people think they are defending.
What to do with it
None of this means leave. It means price both paths in the same paper, with the same categories, over the same timeframe, with the rebuild work and the retraining included in both columns.
If staying still wins, you have a defensible decision and a board that knows what it approved. If it does not win, you found out before the money went out rather than eighteen months into it.
Worth saying plainly: replacement projects do fail, familiarity has a real value that is easy to underestimate, and there are organisations that should stay exactly where they are. The point is that it should be a decision, not a default.
Where your data sits either way: hosting, access and audit, answered in writing.
One essay at a time, straight to your inbox.
Writing on how member organisations actually run, from twenty years inside their systems. No product announcements dressed as insight, no drip campaigns. An essay, when it is ready.
Unsubscribe any time, with one click, and it actually works.
Asked before the scoping call.
What is the difference between an upgrade and a re-implementation?
How can I tell which one I have been quoted?
Why does the label matter?
Where do I find out what breaks before the scoping call?
Does this mean we should leave our current platform?
The writing is the thinking. Nexy is where it gets built.
See what a platform built to hold looks like against your organisation's actual requirements, or run the numbers yourself first. Both are on the table, in the open.