Service
Build a service platform you actually own
We design, build and migrate custom replacements for ServiceNow — so you keep the processes that work, drop the licence model that does not, and host the result in Europe under your own control.
Why organisations do this
A ServiceNow replacement is not a cost-cutting exercise dressed up as a project. It is a decision to stop renting a platform whose price grows with your headcount, and to own the small number of processes that genuinely run your service operation.
It is the right answer for organisations paying enterprise platform prices for a fraction of the platform, for organisations whose customisation has become a dependency rather than an advantage, and for organisations that cannot accept US jurisdiction over their operational data.
It is the wrong answer for the minority who genuinely use the breadth of the platform and get value from it — and we will tell you if that is you, in the first conversation rather than the fourth. For everyone else the economics now favour owning it, and not by a small margin.
Why building is realistic now
Three years ago we would have talked most organisations out of this. The cost of building and maintaining custom software was high enough that renting a platform was rational even at uncomfortable licence prices.
That is no longer true. AI-assisted development changed the arithmetic: a well-specified workflow application — which is structurally what a service management platform is — is now built by a small team in a fraction of the time it used to take. For the scope a replacement actually produces, a handful of workflows carrying real volume and a defined set of integrations, building now beats renting on cost, on fit, and on ownership.
We are not theorising. A custom replacement is in delivery now on exactly this basis, and the client’s own business case puts the recurring saving at about DKK 3m a year — roughly €400,000, every year, against a build cost paid once. Two further organisations are in discussion.
What makes it work is discipline, not tooling. AI amplifies the judgment directing it — sound architecture gets built faster, and so does unsound architecture, in greater volume. So we fix scope before generation starts, design the data model up front, write down the integration contracts, encode the business rules as tests, and have every line reviewed by someone who could have written it. Fast, and boringly well-engineered.
How we run it
Five phases. The first one decides whether the other four are realistic, which is why we will not skip it.
-
Analysis
We establish what is genuinely in use — which workflows carry volume, which integrations are live, which customisations encode business logic that exists nowhere else, and who actually uses the platform. This routinely cuts assumed scope substantially, and that reduction is the largest saving available in the whole programme.
A defensible scope, an integration inventory, and a business case built on real usage rather than assumption.
-
Development
We build the processes that carry volume first, properly, before anything else — AI-assisted throughout, with every line reviewed. Each carried-forward customisation needs a named owner who can justify it against current business need; anything without one does not get built. You end up with a platform shaped by what you do now, not by a decade of accumulated workaround.
A working target platform covering the processes your operation actually depends on.
-
Migration
Configuration and reference data, open records, and a defined window of recently closed records move across. Older history goes to a read-only archive that satisfies audit and retention without carrying cost and risk into the new platform.
Operational data in place, historic data archived and accessible, nothing silently lost.
-
Go-live
Both platforms run in parallel for a defined period with one rule: new records are created only in the new platform from the cut-over date. Without that rule parallel running never ends and you pay for both. We set the date early, communicate it widely, and hold it.
A controlled cut-over with the service desk operating normally throughout.
-
Hypercare
Four to eight weeks of elevated support after go-live: daily triage, a named response team, a fast path from broken to fixed, and visible tracking of what is being resolved. This is where adoption is won, and it is the phase most often cut when a programme is late. We protect it.
Users who trust the new platform, and a clean hand-back to business-as-usual support.
This is in delivery now
A Nordic group with global operations had grown a heavily customised ServiceNow estate over several years. Service operations depended on it, the licence position grew at every renewal, and a large share of what had been built was no longer used by anyone.
The analysis phase established what was actually in service — a materially smaller footprint than the estate suggested. That became the scope for a custom-built replacement covering the processes the operation genuinely runs on, hosted in Europe, owned outright, with no per-user licence growth.
It is being delivered now, through the five phases above. The client’s own business case puts the recurring saving at about DKK 3m a year — roughly €400,000 — against a build cost paid once and a maintenance line that is a fraction of the licence it replaces. Two further organisations are in discussion on the same basis.
The DKK 3m figure is the client’s own projection, made when the scope was fixed, and the project is still in delivery — it is not yet a realised saving, and we will publish the outturn when there is one. Client named on request. Reference call available.
Guides in this series
There is no single best ServiceNow alternative, because organisations leave for four different reasons: licence cost growth, customisation lock-in, US jurisdiction, and paying for capability they never use. The realistic options are renegotiating, moving to another vendor, or building a custom replacement — and the third has become genuinely viable for narrow, well-specified scopes now that AI-assisted development has cut the cost of building. Establish which reason is yours before evaluating any option.
- Why organisations leave ServiceNow The four reasons European organisations replace ServiceNow — licence growth, lock-in, US jurisdiction, unused capability — and how to tell which is yours.
- What ServiceNow actually costs The licence model explained, why the bill grows faster than your usage, and how to work out your real cost before anyone quotes you an alternative.
- ServiceNow alternatives compared The realistic options for a European organisation leaving ServiceNow, with jurisdiction noted — because for many buyers that is the reason they are leaving.
- Renegotiating your ServiceNow contract Often the cheaper answer than leaving. What actually moves a renewal, what does not, and how to build a credible position without bluffing.
- Build or buy: replacing service management A decision framework with an honest cost model, and the four conditions that have to hold before building your own is the rational answer.
- How to migrate off ServiceNow without breaking operations A practical sequence for replacing ServiceNow: what to map first, what to leave behind, how to run parallel operation, and where these programmes fail.
- Building a ServiceNow replacement with AI-assisted development AI-assisted development has made building your own service platform cheaper than renting one. What we have learned delivering it, and what makes it hold.
- What to do with the CMDB when you leave ServiceNow The hardest technical piece of any ITSM migration, and the one most likely to be discovered late. What to migrate, what to rebuild, what to drop.
Common questions
- Is this cheaper than staying on ServiceNow?
- Usually over a multi-year horizon, and the saving comes from two places: no per-user licence growth, and building only what you use rather than what you once built. On the replacement we have in delivery, the client’s business case puts the recurring saving at about DKK 3m a year. But there is real up-front investment, and if your usage is broad and growing, staying can be the better economic answer. The analysis phase is what tells you which case you are in.
- What happens to our integrations?
- They are inventoried in the analysis phase, before scope is fixed, because integrations move the timeline more than workflow or user counts do. Each one gets an owner and a decision: rebuild, replace, or retire. Discovering integrations late is the single most common cause of slippage in this kind of programme.
- Who owns and maintains the result?
- You do. That is the point. We build it with your people involved throughout so the knowledge stays in your organisation, and we hand over documentation and the operating model at the end of hypercare. If you want continued advisory afterwards that is a separate, ongoing arrangement — not a dependency built into the delivery.
- Where is the replacement hosted?
- Wherever your sovereignty requirement dictates, and we help you define that precisely rather than assuming it. For organisations that need to be outside US jurisdiction, that means an EU-owned provider — not a US provider with an EU region, which does not remove CLOUD Act exposure.