The First Ninety Days After You Switch Your ServiceNow Partner Mid-Project

A programme director at a mid-cap European insurer called me at eight on a Sunday evening. Her Big 4 partner had just filed a fourth timeline slip on a fifteen-month HRSD and ITSM programme that was now approaching twenty-two months. The steering committee had voted on Friday to switch. Her question was not whether the decision was right. It was, “What do I actually do on Monday morning.”

That is the conversation nobody in the sales cycle prepares you for. Everyone tells you how to build the business case to switch ServiceNow partner. Almost nobody tells you what the first ninety days after the switch actually look like, or how you avoid trading one broken programme for another one. Firing the incumbent is the easy part. The next thirteen weeks decide whether the switch was worth the fight.

This post is the playbook I hand to clients in the first two weeks after they make the call. It is not a marketing framework. It is what has to happen, in what order, so the platform is stable, the client team is back in control, and the new partner can actually deliver against a plan that survives contact with the instance.

Week one is not about the new partner

The instinct after a switch is to onboard the replacement partner as fast as possible. Resist it. The first week is not about the new team. It is about you getting the truth about your own instance from people who can no longer bill you to obscure it.

The single most valuable artefact in week one is a read-only export of every open work item the incumbent was tracking. Update sets in progress, stories in the backlog, defects in triage, the change queue for the next four weeks, the integration monitoring dashboards, the deployment pipeline status. Get it in writing before the incumbent’s team starts winding down. Nine times out of ten there is at least one work stream that only exists in a single senior consultant’s head, and once that person’s project code closes, the knowledge walks. You want the extraction done before the notice period ends, not after.

The second week-one move is a technical audit of the instance in its current state. Not from the incumbent, obviously. Either your own platform owner or a third party you trust runs a health check that answers three questions: what is genuinely broken today, what is technically debt that will fail within six months, and what is the scope of undocumented customisation that will slow the next partner down. Every switch I have supported has surfaced at least one large customisation nobody had documented, and usually a couple of integrations running on credentials only the outgoing partner had access to.

The third move is a stakeholder inventory. Who inside your organisation had a direct working relationship with the outgoing partner. Which client stakeholders will interpret the switch as political rather than technical. Which internal sceptics need to be brought in early so they do not become obstacles at the first steering committee under the new partner. This is not political theatre. If you skip it, the new partner walks into a room where half the audience is quietly cheering for them to fail.

Weeks two to four: stabilise before you accelerate

The temptation in weeks two to four is to hand the new partner the original roadmap and tell them to catch up. Do not do this. The original roadmap was built by the team that just lost the contract, on a set of assumptions the platform has since disproved. Handing it over uncritically is asking the new partner to inherit a plan they cannot defend.

The right move is a joint replan. The new partner takes the audit findings from week one and works with your platform owner to produce a stabilisation plan first, before any new scope resumes. Stabilisation covers three areas: any production issues that are actively harming users, any technical debt that will block the next release, and any integrations or scheduled jobs that are silently failing or degrading. In the average switch I see, stabilisation takes four to six weeks of focused work. It is not glamorous, it does not deliver new features to the business, and it is absolutely non-negotiable. If you skip it and go straight to new development, you will spend the next six months fighting production fires that predate the new partner.

The counter-argument you will hear from your own leadership is that stabilisation looks like a delay, and delays after a partner switch make the CFO nervous. The right framing back is that stabilisation is exactly what the previous partner was not doing, and it is why you are switching. Producing a stabilised platform in six weeks and then resuming feature delivery is a stronger story at the next audit committee than pretending you can catch up on twenty-two months of drift in eight.

Contract mechanics that do not get discussed in the sales cycle

Two contract questions decide whether the first ninety days feel like a rescue or a second round of chaos. Both need to be answered before the ink dries on the new partner’s engagement.

The first is who owns the update sets and the code that the incumbent has already deployed to production. In principle this is your intellectual property because you paid for it. In practice, the outgoing partner will often claim shared ownership of frameworks, script includes, and reusable components they consider proprietary. Get the ownership question resolved in writing during the exit negotiation, not three months later when the new partner needs to modify something the incumbent’s legal team suddenly claims as their template code. If the exit contract is silent on this, assume friction.

The second is credentials, MID server access, integration accounts, and non-production instance ownership. The incumbent will have accumulated integration users, admin accounts, scheduled job runners, and API credentials over the life of the engagement. Some of these will be tied to individuals who are about to lose access. Others will be shared service accounts nobody has rotated in eighteen months. Week one includes a full audit of every non-human account with elevated access, and a rotation plan that is complete before the outgoing partner’s contract terminates. If you do this after the exit, you will spend the next four weeks discovering broken integrations that nobody predicted.

The third quiet question is what happens to any customisations the incumbent built in their own instance for demonstration or development purposes. Some Big 4 partners maintain private demo instances that reference your data model, your naming conventions, or in some cases pieces of your actual configuration. Ask, in writing, what will happen to those artefacts on contract termination. If the answer is unclear, escalate it to your general counsel. This is not paranoia. It is a normal part of a mature switch.

Where an independent ServiceNow partner earns the switch back

The framing that sells the switch to the audit committee is usually cost or delivery velocity. The framing that makes the switch pay off over eighteen months is different. It is that an independent ServiceNow partner has no incentive to expand scope for its own margin and every incentive to stabilise your platform quickly so that the ongoing engagement is defensible on outcomes rather than headcount.

A Big 4 model rewards billable hours on a fixed set of named consultants. An independent boutique model rewards outcomes on a fixed price for a defined piece of work. Neither model is intrinsically better. But in a rescue situation, the boutique model is structurally aligned with what you need in the first ninety days, which is fast, decisive stabilisation and a shorter roadmap. If the new partner you are onboarding is quoting time and materials on a large open-ended engagement, you are recreating the same incentive problem you just paid to escape.

The other pattern worth naming is transparent access to the instance during the transition. The right new partner will give your internal team full read access to their engagement backlog, their delivery pipeline, and their non-production instance work from week one. If the new partner starts creating information asymmetries in weeks two and three, that is the same failure pattern that produced the switch in the first place, and you should surface it in the first steering committee, not the sixth.

Where to start, practically

If you are approaching a switch in the next quarter, the actions that matter most in the first two weeks are these.

Get an independent read on your current instance before the outgoing partner’s contract ends. Do not rely on the incumbent for their own exit assessment, and do not wait for the new partner to complete a discovery phase before you understand the platform’s real state.

Extract every open work item, credential, integration configuration, and undocumented customisation from the outgoing team in writing, with sign-off, before the notice period expires. Anything not extracted before the last day is functionally lost.

Insist on a joint stabilisation plan from the new partner in weeks two to four, before any new feature scope resumes. A four to six week stabilisation window is normal and defensible at any audit committee.

Rotate credentials, integration accounts, and service users before the outgoing partner loses access, not after. Assume nothing about what will keep working once shared accounts are cycled.

If you are in the middle of this and want a second opinion on the technical state of the instance you are about to inherit, our fixed-fee ten-day Instance Health Report is designed precisely for this situation. It gives you a written, defensible view of what you actually have before you sign the new partner’s statement of work. You can also see how we structure independent ServiceNow consulting engagements as fixed-price outcomes rather than open-ended billable hours.

Mladen Milic runs Milic Media Kft, a boutique ServiceNow consultancy delivering implementation, health audits and HRSD work across the EU. Reach him at mladen@milicmedia.com.