+44 (0)203 479 7900
+1 612 416 2177
+61 (0)2 8880 9500
+64 (0)4 488 7481How to replace a legacy service management platform in central government
Replacing a government ITSM platform is not primarily a software-selection exercise. It is a controlled change program that has to manage legacy risk, service continuity, constrained budgets, security, governance and organizational capacity at once. This guide sets out how to decide whether to replace, build the case, procure, and migrate, without creating unacceptable operational risk.
Source: DSIT, State of Digital Government review (January 2025)
The UK government has been unusually candid about its own technology. The Department for Science, Innovation and Technology's State of Digital Government review, published in January 2025, estimated that an average of 28 percent of central government technology is classed as legacy: end-of-life, out of support, impossible to update, no longer cost-effective, or otherwise above an acceptable risk threshold. The figure ranges widely between organizations, from around 10 to 60 percent, and has risen from 26 percent in 2023. The review is also clear that there is no comprehensive record of legacy IT across central government, so these are estimates rather than a precise audit.
What is not in doubt is the cost. Against roughly 26 billion pounds of public sector technology spend in 2023, the review found that maintaining legacy systems often costs three to four times as much as modern alternatives, and that 22 percent of the legacy systems it assessed were "red-rated" for high failure potential. Service desks sit near the center of this estate. They are often among the oldest and most heavily customized systems a department runs, touching every team, which makes them both a prime candidate for modernization and one of the riskiest things to change.
This guide is written for the people who carry that decision, typically a group spanning the CIO or CDO, service management leadership, enterprise architecture, security, information governance, procurement, finance and operational teams, and often more than one agency or arm's-length body. It covers how to decide whether to replace, how to justify it, what to require, how to reduce the risk, and how to procure, with Alemba Service Manager offered as one credible answer to the criteria the guide sets out.
Why legacy service management has become a government priority
Legacy tools rarely survive because they are good. They survive because replacing them is hard, and government conditions make it harder than most: multi-year modernization against shorter funding and political cycles, the time and specialist effort of compliant procurement, justified caution about changing live services, and the need to keep different agencies' data and governance separate. None of these are reasons to keep a legacy service desk. They are reasons the replacement has to be planned properly, which is where the real risk, and the real opportunity, sits. For the wider picture of how structured IT service management supports government, see our central government service management overview.
When should you replace rather than maintain your platform?
"The system is old" is not, on its own, a case for replacement. A government buying committee needs observable indicators. The signals below are the practical questions to ask of your current platform. They are deliberately vendor-neutral: use them to assess any system, including your incumbent.
| Signal | Question to ask |
|---|---|
| Supportability | Is the product or version approaching end of support? |
| Security | Can it meet current security requirements and patching expectations? |
| Cost | How much effort goes into maintaining customization and infrastructure? |
| Change velocity | Can service owners change workflows without a development project? |
| Integration | Can it connect cleanly to identity, monitoring, HR, finance and other systems? |
| Data | Can historical records be retained, searched, governed and migrated reliably? |
| Resilience | Does it meet current availability and recovery requirements? |
| User experience | Are staff bypassing the system because it is hard to use? |
| Governance | Can access, approvals, changes and exceptions be demonstrated to auditors? |
| Consolidation | Are different departments or agencies maintaining duplicated tooling? |
| Skills | Does the organization depend on a few people who understand the system? |
| Technology risk | Is the platform creating dependency on obsolete technology or scarce expertise? |
Reading the result
Where several of these conditions apply at once, the question is often no longer whether there is technical debt, but whether continuing to fund it represents an acceptable level of operational risk. That reframing, from "is it old?" to "is the risk acceptable?", is usually what moves a replacement from backlog to business case.
Building the business case under constrained budgets
The review found that 28 percent of red-rated legacy systems lack remediation funding, and pointed to a mismatch between how government funds capital and day-to-day resource spending. So a credible case has to work within constraint, not assume new money. The single most useful principle: compare five-year total cost and risk, not simply incumbent license cost against replacement license cost.
The cost of doing nothing
Support and maintenance, scarce specialist legacy skills, hosting and infrastructure, duplicated tooling across departments, manual workarounds, outages, security remediation, and the cost of every change being a project. These are real and recurring, and they rise as the estate ages.
The cost of change
Licenses or subscription, implementation, migration, integration, testing, training, a period of parallel running, internal project capacity, and decommissioning the old system. Setting the two honestly against each other over five years is what stands up to finance and procurement scrutiny, and it is a far stronger argument than a license-to-license comparison.
What can go wrong during replacement
Consolidating onto a modern platform is often the right direction. But where duplicated platforms create unnecessary cost, fragmented reporting or governance complexity, consolidation helps only if the target architecture preserves the organizational and data separation government requires. A rushed or poorly scoped migration can create new problems in place of the old ones. Four recur:
1. Data migration and history loss
Years of tickets, assets, knowledge and audit history live in the old system. Losing or corrupting that undermines both service continuity and the audit trail government accountability depends on.
2. Service continuity during cut-over
If the new platform carries critical load before it is ready, or the old one is retired too soon, live services suffer. Many high-risk migrations use a controlled period of parallel operation or a staged cut-over to manage this. Parallel running is not automatically the safest option, though: it carries its own synchronization and operational overhead, so the approach should be chosen deliberately.
3. Governance gaps
A new tool without role-based access, segregation of duties and complete audit logging can leave a department less compliant than before. Governance has to be designed in, not retrofitted.
4. Re-platforming lock-in
Replacing one heavily custom-coded system with another just resets the clock. If every change needs a developer, the new platform becomes tomorrow's legacy. Configurable, no-code workflow platforms reduce this risk.
Security and governance requirements to define before procurement
For central government these are procurement gates, not supporting features. Define them as requirements first, then ask each shortlisted supplier to evidence how they are met. The list below is written as buyer criteria, not product claims.
| Area | Define and require |
|---|---|
| Identity & access | SSO, MFA compatibility, role-based access control, privileged access management, joiner/mover/leaver controls, segregation of duties |
| Auditability | Appropriate audit trail, record of workflow and configuration changes, approval history, traceability of administrative activity |
| Data protection | Hosting and data residency, retention, classification, encryption, export, deletion, backup and recovery |
| Operational resilience | Availability, disaster recovery, RTO/RPO, incident response, supplier continuity, exit provisions |
| Multi-agency governance | Partition or tenant isolation, delegated administration, agency-specific workflow, independent reporting, shared catalog where appropriate |
| Assurance | Recognized certifications and standards, with the exact scope made clear by the supplier |
How Alemba addresses these
Alemba Service Manager provides role-based security roles and segregation of duties, administrative audit trails, and partitioning for multi-agency separation (described in the migration model below). It supports ITIL-aligned practices independently verified through PinkVERIFY. Where specific certifications or assurance scope are needed for an evaluation, request them directly so the exact, current scope is confirmed rather than assumed. Stating the government criteria first and the Alemba answer second is deliberate: the criteria stand on their own, whichever platform a department chooses.
A phased migration model that respects capacity
Enterprise migrations rarely fail for lack of technology. They struggle with capacity: process owners on business-as-usual, scarce security and architecture time, and limited testing and change-management resource. A phased model is as much about managing that as managing risk.
- Wave 0
Foundations
Platform, identity, security and governance set up first, so everything that follows inherits the right controls rather than retrofitting them.
- Wave 1
One lower-risk service
Prove the approach on a contained service, run old and new in parallel through cut-over, and let teams learn the platform before it carries critical load.
- Wave 2
Core IT workflows
Migrate the main incident, request and change workflows once the model is proven, configured through no-code tools rather than development projects.
- Wave 3
Other departments and agencies
Extend to further bodies using partitioning, so each keeps its own workflows, configuration and logical data set within one system, with some reference data shared where appropriate and role-based access governing what each sees.
- Wave 4
Enterprise service management
Extend beyond IT to other service functions on the same governed platform with enterprise service management, consolidating tooling and reporting as capacity allows.
Don't recreate the legacy platform inside the new one
Migration programs often assume every record, configuration and workflow must move. That is how a fresh platform inherits the complexity it was meant to escape. Treat the migration as a chance to rationalize: retire obsolete workflows, simplify approvals, consolidate catalogs, standardize where organizational difference is not genuinely required, and archive rather than migrate historical data that does not need to be live, while preserving the records and audit history that governance genuinely requires. Deciding deliberately what not to migrate is one of the highest-value steps in the whole program, and it is what keeps the new platform from becoming the next legacy system.
Structuring procurement, and buying through G-Cloud 15
For UK central government the procurement route matters as much as the platform. A useful pre-procurement checklist, before any supplier conversation:
- Define outcomes, not product features
- Document existing-system dependencies
- Identify mandatory security and assurance requirements
- Define migration scope and historical-data requirements
- Decide SaaS and hosting constraints
- Determine integration requirements
- Establish evaluation weightings
- Include implementation and migration capability, not just the software
- Require transparent whole-life cost
- Define exit and data-portability terms up front
- Validate reference customers of comparable complexity
- Agree measurable acceptance criteria
For UK buyers, the G-Cloud 15 framework on the Digital Marketplace provides a compliant route with published service definitions, pricing and documentation, avoiding a lengthy bespoke procurement. Alemba Service Manager is listed under Lot 2a (Infrastructure Software as a Service) and Lot 2b (Software as a Service). Whichever route you take, the binding constraint is usually delivery risk rather than appetite for change, which is exactly what a phased, governed, framework-procured approach is designed to manage.
What to look for in a modern government ITSM platform
Separate the criteria from the vendor. The table below is what a government buying committee should require of any ITSM software, with the evidence to ask for so claims are demonstrated, not asserted.
| Requirement | Why government teams need it | Evidence to request |
|---|---|---|
| Configurable (no-code) workflows | Reduce dependency on developers and avoid re-platforming lock-in | Live demonstration using a real process |
| Role-based access & SoD | Maintain separation of duties and least privilege | Roles and permissions model |
| Auditability | Support governance and investigations | Audit-log demonstration |
| Partitioning / isolation | Support shared services securely across agencies | Data-isolation architecture |
| Integration capability | Avoid creating another silo | API and integration documentation |
| Data portability & exit | Reduce lock-in | Export and documented exit process |
| Service continuity | Protect critical operations | SLA and DR documentation |
| Reporting | Governance and service performance | Example operational dashboards |
| Migration tooling | Reduce implementation risk | Migration methodology and references |
| Transparent whole-life cost | Support budget scrutiny | Three-to-five-year cost model |
| Comparable references | De-risk supplier choice | Government customer references |
Alongside the core service desk, ask how the platform handles configuration data across agencies, for example through a federated CMDB, and how staff will reach it, ideally through a self-service portal that does not need a license per user.
A worked example: consolidating across agencies
Starting point
A New Zealand government agency ran IT service management that it wanted to evolve into a full enterprise service management capability serving multiple agencies, rather than maintaining separate tooling.
Approach
Working with Alemba, it consolidated onto a single governed platform, using partitioning to keep each agency's workflows, configuration and data separate within one system under a shared-services operating model: the multi-agency, partitioned approach described above, in practice.
Outcome
Streamlined workflows and increased automation across agencies on one platform, with service management extended beyond IT.
Read the New Zealand government agency case study →Outside the UK: what changes?
The migration principles above are jurisdiction-independent: establish the legacy risk, define governance before migration, phase the transition, and protect service continuity. What differs by country is procurement and assurance. In the UK, G-Cloud 15 and UK security and procurement requirements apply, as above. In Ireland, public procurement follows national and EU rules. In Australia and New Zealand, government buyers work within their own cloud, security and procurement frameworks, both of which now provide current guidance on modernizing away from legacy systems. The decision framework in this guide applies in each; the specific route to market does not. For regional service management detail, see our central government and local and state government pages.
Central government ITSM replacement FAQs
When should central government replace rather than maintain a legacy service desk?
The decision usually turns on risk rather than age. If the platform is out of support, cannot meet current security expectations, depends on scarce specialist skills, blocks integration, or forces development projects for routine change, the cost of continuing to maintain it may exceed the cost and risk of replacing it. Where several of these conditions apply at once, continuing to fund the legacy system is often the higher-risk option.
How do you build a business case for replacing government ITSM under budget constraints?
Compare five-year total cost and risk, not simply incumbent license cost against replacement license cost. Set the full cost of doing nothing (support, specialist skills, hosting, duplicated tooling, manual effort, outages, security remediation) against the cost of change (subscription, implementation, migration, integration, testing, training, parallel running, internal capacity, decommissioning). Framing it as whole-life cost and risk is what stands up to finance and procurement scrutiny.
Can multiple government agencies share one ITSM platform?
Yes. Alemba Service Manager uses partitioning to divide a single system into separate functional areas, each with its own workflows, configuration and logical data set, while some reference data such as people and locations can be shared where appropriate. Role-based access controls what each analyst can see across partitions, which supports shared-services and multi-agency models without departments sharing sensitive data, from a single database rather than separate systems.
How is ITSM procured through G-Cloud 15?
UK public sector buyers can procure ITSM software through the G-Cloud 15 framework on the Digital Marketplace, where service definitions, pricing and documentation are published. Before going to market it helps to define outcomes rather than features, document existing dependencies, set mandatory security and assurance requirements, and agree whole-life cost and exit terms. Alemba Service Manager is listed under Lot 2a (Infrastructure Software as a Service) and Lot 2b (Software as a Service).
What should central government look for in a modern ITSM platform?
Separate vendor-neutral criteria from any single product. Government teams should require configurable (no-code) workflows, strong role-based access and segregation of duties, complete audit trails, data portability and a clear exit process, integration capability, service continuity and recovery commitments, transparent whole-life cost, and reference customers of comparable complexity. Ask for each to be evidenced in a demonstration rather than asserted.
What is the biggest risk when migrating off a legacy government service desk?
Losing service continuity or audit history during the transition. The most controlled migrations move one service or agency at a time, use a staged cut-over or a defined period of parallel operation, and decide deliberately what historical data to migrate, archive or retire rather than copying everything across.
How do you avoid vendor lock-in when replacing ITSM?
Define exit and portability terms during procurement, not at contract end. Require data ownership, bulk export in open formats, documented configuration, API access, data retention after contract end, and transition support. A platform that is configurable without developers also reduces lock-in by keeping change in the hands of the organization rather than the supplier.