Leaving ServiceNow feels risky for a simple reason: the service desk cannot stop while you move it. Tickets keep arriving, customers keep expecting answers, and the integrations that link you to them have to keep working on the day you switch.
An eight week exit is realistic when three things are true. The scope is agreed before work starts. The work runs in a fixed order, so nothing is discovered late. And the price is fixed, so nobody has a reason to stretch the timeline. This is the order we use with QuellDesk, week by week, and what to prepare on your side.
Before week 1: five decisions to make
Most migration delays are decisions that nobody made early enough. Settle these before the plan starts.
- What moves. At a minimum: tickets with their history, your assets and your customer organisations. Decide whether you need every closed ticket or a window of years, and who signs that off.
- Which customer integrations must survive. If your customers raise tickets in their own systems and expect yours to stay in step, list those links. The QuellDesk plan includes two way eBonding with up to three of them.
- Which monitoring feeds raise incidents. List every source that creates work today, so alerts keep flowing on the day you switch.
- Who accepts the result. Name one reviewer per role: a service desk agent, a resolver, a change manager, a customer facing lead. Acceptance is faster when it is owned.
- Which service tier you need. Uptime, recovery objectives and support hours differ by tier, and the right one depends on the promises you make to your own customers.
Weeks 1 and 2: discovery and mapping
The first two weeks map your data, workflows and integrations onto QuellDesk, and build your production environment. Building production early is deliberate: the testing in weeks 6 and 7, including a production load test, happens on the environment you will actually run.
What to prepare: access to export your ServiceNow data, your ticket types and the fields you rely on, your service level definitions, and your list of customers.
Weeks 3 to 5: migration and integration
This is the heavy lifting. Tickets move with their history, along with your assets and customer organisations. Two way eBonding is set up with up to three of your customers’ ticketing systems, your monitoring feeds are connected, and your configuration is built.
What to prepare: a short freeze on configuration changes in the old platform during these weeks. Every change made there now is a change that has to be made twice.
Weeks 6 and 7: acceptance and training
Before anyone switches, the new desk is proven. These two weeks cover acceptance testing, a production load test, a role by role check of every screen, and training for your team.
The role by role screen check matters more than it sounds. A migration is judged by the people who use it all day, and each role sees a different product. Checking every screen as each role catches the gaps that a generic test plan misses.
What to prepare: your named reviewers, with time set aside in their calendars.
Week 8: cut-over and go-live
Cut-over is a planned event, not a surprise. Your desk moves to QuellDesk and goes live.
What to prepare: a short note to your customers about the switch, and to anyone who raises tickets by email, so nobody is caught off guard.
Weeks 9 to 12: hypercare
The first weeks on a new platform surface small things: a field someone misses, a report a manager expected, a rule that needs tuning. Hypercare runs for 30 days after go-live with daily check-ins, so those are handled while they are still small. After that, support continues in your service tier’s hours.
Why the fixed price matters
A migration billed by the hour has no natural end. A fixed price agreed before work starts changes the incentive: the plan has to be right at the beginning, because the cost of getting it wrong falls on the people who wrote it. It also means you can put the move in a budget and know it will stay there.
The checklist
- Decide what data moves, and who signs it off
- List the customer integrations that must keep working
- List every monitoring source that raises incidents
- Name one acceptance reviewer per role
- Choose the service tier that matches the promises you make
- Freeze configuration changes in the old platform during weeks 3 to 5
- Tell customers about the cut-over before week 8
If you want to see how this plan would look for your desk, the week by week plan is here, or book a 30 minute demo and we will walk through it with your setup in mind.