Standing up owned ITSM during a managed-services transition

The challenge

The operator had decided to change managed service providers. On paper it looked like a straightforward commercial move. In the details there was a trap. The entire IT service management environment, the system of record for every incident, request, and change, ran on the outgoing MSP’s ManageEngine platform, inside the MSP’s own tenant. The operator didn’t own it. When the contract ended, so did access to years of process and history. Before it could safely move, the operator needed its own service management platform stood up, configured, and trusted, with no gap in day-to-day IT support in the meantime.

That is a harder place to be than it looks. You are rebuilding the cockpit while the plane is in the air, on a deadline set by the contract you are trying to exit. Every user still expects their tickets to get handled. This is the kind of transition that goes sideways when nobody owns the whole picture.

What we did

Our job was to make the transition happen and keep it coherent. We set the target architecture and led the build of ServiceNow as the operator’s own platform. That replaced the MSP-owned ManageEngine service desk with something the operator actually controls. In practice it meant standing up the platform and running the program while we coordinated every team and vendor involved, so a high-stakes migration didn’t stall in the gap between two providers.

Rather than trying to do everything at once, we started with a deliberate pilot. Joiner-mover-leaver, onboarding, internal moves, and offboarding, became the first real app on the new platform. That was the right starter integration: high-value, well-bounded, and enough to prove the data model and the patterns before we scaled anything up. Where hands-on engineering was the fastest way to unblock it, we did it ourselves. The REST API behind the pilot was ours to build. It drove ticket creation in ServiceNow and fired the downstream actions, data imports, and transformations that made the workflow real.

From there the platform grew, and our job stayed the same. We kept leading and orchestrating as it went. We brought in a Microsoft Teams bot so employees could raise and track requests from the tool they already live in. We also added an email-based helpdesk, so inbound mail becomes structured and routed tickets instead of vanishing into a shared inbox. We led the configuration of change management and a steadily growing library of more complex workflows as the operator’s needs matured.

Standing up the platform was only ever half the job. Alongside it, we managed the program and drove the organizational transition off the outgoing provider. Then came the training, for everyone who had to live with the new platform, from employees to IT staff to business stakeholders. Technology transitions fail on the human side far more often than the technical one, so we treated enablement as core work rather than a footnote.

Why it mattered

The real win was ownership. Before, the operator’s ability to run its own IT support lived inside someone else’s tenant and depended on someone else’s goodwill. After, it owned the platform, the workflows, the data, and the processes, with teams trained to run them. Changing providers stopped being a hostage situation and became a normal commercial decision. That is the difference between renting your operations and owning them.

What’s next

The platform is a foundation, and the work continues. Current fronts include reporting and analytics, IT operations management (ITOM), and deeper integration with the rest of the estate.

The range it took

This was a program to lead, not just a system to build. The work spanned architecture and platform configuration, the program itself, an organizational change, and the training, with every team and vendor coordinated throughout. Where a piece of engineering was the fastest path forward, we built it ourselves. The joiner-mover-leaver REST API is one example. It ties requests to tickets to downstream automation. Knowing when to orchestrate and when to roll up your sleeves, and being able to do both, is what kept a high-stakes migration coherent instead of stalling between vendors.