First, be clear about why
Replacement projects that struggle usually began with dissatisfaction rather than a defined objective. 'The current system is frustrating' is a real signal, but it is not a specification. Before evaluating anything, articulate what needs to be true afterwards.
Common legitimate drivers include: the annual buyback cycle consumes disproportionate officer time; schools find purchasing difficult and say so; commercial reporting requires manual assembly; pricing models cannot be represented properly; the finance handover is manual; the supplier's roadmap has stalled; or contract renewal has created a natural review point.
Write these down as outcomes with measures attached. They become your evaluation criteria, your implementation priorities and your success assessment.
Understand what you actually depend on
Legacy systems accumulate dependencies that nobody has documented. Before replacing one, establish what it is genuinely doing:
- Which service areas rely on it, and for which parts of their process.
- What data it holds that exists nowhere else — historic orders, contract terms, pricing history, customer contacts.
- What it feeds: finance exports, reports, mail-merges, statutory returns.
- Which workarounds exist around it, and what each one compensates for.
- Who the informal experts are, and what only they know.
This exercise routinely surfaces requirements that would otherwise appear late in implementation, which is the most expensive time to discover them.
Data migration is the main risk
Migration difficulty is determined by data quality far more than by technology. Assess yours honestly across the areas that matter:
- 1
Organisations
Schools, academies, trusts, nurseries and other customers, with correct names, types, identifiers, addresses and current pupil numbers. Duplicates and closed or converted schools are common.
- 2
Contacts
Named contacts with roles and permissions. This is often the weakest dataset, because it lives in individual mailboxes.
- 3
Services and products
The catalogue at the right granularity, with descriptions and current-year pricing rules — not just last year's calculated totals.
- 4
Contracts and entitlements
Active arrangements with start and end dates, agreed prices, and any consumed allowance to date.
- 5
Financial history
Decide deliberately how much transactional history moves across. Full history is rarely necessary; a defined period plus an archive is usually sufficient.
- 6
Historic decisions
Previous renewal and decline history is commercially valuable. If it can be extracted, it is worth migrating.
Check that your pricing can actually be modelled
Pricing is where replacement projects most often hit an unexpected wall. Traded-services pricing is rarely simple: per-pupil rates, banded pricing by school size, tiered volume pricing, fixed fees, minimum charges, bundled packages, multi-year commitments, trust-level arrangements, early-payment or loyalty discounts, and negotiated exceptions.
Test your most awkward real examples against any candidate platform, not the straightforward ones. If unusual arrangements can only be handled by manual overrides, you will be maintaining a parallel spreadsheet again within a year.
Time the change around the buyback cycle
Annual buyback is the least forgiving deadline in the operation. Schools need to make decisions in a fixed window, and that window cannot move because a system implementation slipped.
Two broad approaches exist. Either implement well ahead of the cycle so the new platform runs it, with time for configuration, testing and communication; or run one more cycle on the existing system and cut over immediately afterwards, when the operation is at its quietest. Attempting to switch mid-cycle is the option to avoid.
Integrations and the wider council estate
A traded-services platform does not exist alone. Establish early what it must connect to and how:
- The council's finance system, for transaction export and coding.
- Identity and access management for council staff, and a separate, appropriate access model for school users.
- Any pupil-number or school-data source used for pricing.
- Reporting and business-intelligence tools already in use.
- Email delivery for notifications, and how deliverability to school domains is handled.
Involve digital and IT colleagues before shortlisting, not after. Architecture, hosting, data residency and security review will happen regardless; doing them early avoids re-running a selection process.
Do not overlook the school experience
It is easy to specify a replacement entirely around internal administration and treat the school-facing side as secondary. That is a mistake: schools are the customers, and their experience drives renewal rates, enquiry volume and the council's reputation as a supplier.
Ask specifically how schools discover services, whether they see pricing calculated for their own organisation, how internal approval and purchase orders are handled, whether they can see contracts and remaining entitlements, and whether the interface can carry the council's own branding. Ask to see it as a school user would, not only as an administrator.
Supplier questions worth asking
- What does implementation involve, who does what, and over what timescale?
- How is our data extracted, mapped and validated — and who is responsible if it does not reconcile?
- What happens if we later choose to leave: what data can we take, in what format?
- How is the annual cycle configured, and can we run it ourselves without supplier involvement?
- What is genuinely available today versus on the roadmap? Ask for the distinction explicitly.
- How are changes released, and what testing environment do we get?
- What does support look like during the buyback period specifically?
The last of the roadmap questions matters more than it appears. Being told clearly that something is planned rather than built is a good sign about a supplier, not a bad one — it is the answers that blur the two that create delivery problems later.
Change management inside the council
Service teams have often built their own tools and processes and may reasonably fear losing control or flexibility. Involve them in configuring their own catalogue and pricing, be explicit about what becomes standardised and why, and identify the specific administrative tasks each team will stop doing. A new system that adds visibility while removing no work will not be adopted willingly.
Service Street is being built for this scenario specifically: structured services and products, configurable pricing models, an annual buyback cycle generated from existing contracts, purchase-order and approval handling, transaction export to existing council finance systems, and a white-labelled school-facing portal — with a clear distinction maintained between what exists today and what is planned.
In summary
Replacing a traded-services platform is primarily a data, timing and process exercise rather than a software-selection exercise. Define the outcomes, cleanse the data early, prove your hardest pricing cases, time the cutover around buyback, involve IT and service teams from the start, and insist on a clear line between current and planned capability.