How do I bring a heavily customised ITSM platform back to baseline?

Treat every customisation as guilty until it proves a clear business outcome, then restore the platform in layers: process rules first, workspace second, integrations last. The goal is not a museum of past preferences. It is a service management system you can upgrade, support and explain.

Why this matters

Many organisations started with a capable ITSM platform and then bent it for every special case. Years later, upgrades stall, state models disagree with the workspace, and nobody can say which rules still earn their keep. That is a service excellence problem as much as a technical one. John Sansbury puts the guiding principle plainly in The Journey to Service Excellence: "the more complex a system is, the less reliable it is likely to be and the harder it will be to maintain and repair." Returning toward baseline is how you get that reliability back without throwing away what still works.

John also notes that the industry has already shifted: "More generally, in the last ten years, the decision as to whether to accept the toolset 'out of the box' or to customise it has massively come down in favour of the former." His four reasons are cost, the ability to upgrade, compatibility with other toolsets, and the improved quality of the tools themselves. Use that as your north star when someone defends a ten year old exception.

Practical steps

1. Freeze new custom work. Put a temporary rule in place: no new field, state, business rule or workspace page unless a named service owner writes the outcome it protects and the cost of not having it.

2. Inventory deviations against a clean baseline. Stand up or borrow a vanilla reference instance of the same major release. Compare state models, UI policies, flows, scripts, catalogue items and workspace experiences. Produce a simple register: item, owner, last used, business outcome, upgrade risk, keep or remove.

3. Challenge habit, not just technology. For each keep candidate, ask who would notice if it disappeared tomorrow, and what workaround they would invent. John warns that people often keep doing things "because they have always done them without understanding what, if any, value is being created." If the answer is thin, mark it for removal.

4. Fix the process layer before the workspace layer. State transitions, priorities, assignment rules and fulfilment flows are the source of truth. A modern operations workspace (vendor material: ServiceNow Service Operations Workspace is one example) only presents those rules. Repair the underlying ITSM configuration first, then align the workspace so people are not switching back to a classic UI to finish the job.

5. Prefer configuration and deactivation over clever rewrites. Deactivate unused pages and rules. Retire duplicate experiences. Keep a short approved exceptions list with an expiry date and an owner. Anything without an owner leaves with the next release cycle.

6. Decide greenfield versus in place only after the inventory. If more than half the deviations fail the outcome test, a clean build with controlled migration of catalogue, knowledge and open work can be cheaper than untangling years of overlays. Scope that as time and materials with clear exit criteria, not a fixed price hope.

7. Rehearse an upgrade on the cleaned path. The proof that baseline is back is a successful non production upgrade and a week of live work without falling back to the old screens.

A short worked example

This is an illustrative example, not a client case. A mid size IT team inherited an altered problem management path: extra states, custom buttons and a workspace page that no longer matched the platform. They cloned a clean reference, listed thirty eight deviations, and found twenty one existed only because a previous project had copied a spreadsheet into the tool. They restored standard problem states, deactivated the duplicate workspace page, and kept two fields that finance still used for chargeback. The next upgrade completed in a weekend instead of a six week project. Agents stopped hopping between interfaces because the one workspace finally told the same story as the platform.

Common mistakes

1. Starting in the workspace while the state model underneath is still wrong. You polish the window and leave the hinges broken.
2. Treating every current practice as a requirement. Anchor workshops on baseline capability and ask for the outcome gap, not for a tour of today's screens.
3. Big bang removal with no approved exceptions list. People will recreate the same customisations under new names within a month.
4. Paying for a fixed price return to out of the box without an inventory. You cannot price what you have not counted.
5. Using every feature the licence includes. As John puts it, "simply because you have certain tools and assets available to you to complete a task does not mean that the most efficient way to achieve the outcome is to use all of those tools."

Where to go next

If you are choosing what stays and what goes, the MoSCoW approach in John's tools chapters is a clean way to force the conversation with sponsors, administrators and service owners. On ESM's Exchange you can also read the practical pieces on selecting service management tools and using MoSCoW to prioritise requirements, then apply the same discipline to removing customisations you already own.

Readers who want the fuller argument will find it in John Sansbury's The Journey to Service Excellence, available to Exchange members.

Tags: esm-questions, itsm, service-management, tools, continual-improvement

Sources

• https://www.reddit.com/r/servicenow/comments/1xmn0vp/best_approach_to_bringing_a_heavily_customised/

• https://exchange.esm.institute/knowledge/selecting-service-management-tools-the-right-way

• https://exchange.esm.institute/knowledge/using-moscow-to-prioritise-tool-requirements