Deadline work
Cherwell support ends 31 December 2026
If you are still on it, the decision is already made for you. The only open question is whether the move is planned or rushed. There is still time to do it properly if the inventory starts now.
The deadline is the whole problem
Most platform migrations slip, because most platform migrations can. This one cannot. A vendor end-of-life date does not care whether your requirements workshop overran, and it does not move because your fiscal year is awkward.
That changes what good planning looks like. The work has to be sized to the window rather than to the wish list, the scope has to be cut early rather than late, and the cutover has to be rehearsed rather than attempted. None of that is difficult. It is just unforgiving about being started late.
The bridge
Four moves
This is the shape of a migration that lands. It assumes one senior engineer who owns it end to end rather than a rotating project team, which is how we work anyway.
-
First
Establish how the data can leave
A SaaS tenant is API-only. On-premise gives you the API and direct database access, which changes the plan for attachments in particular. Cherwell exposes a REST API from CSM 9.5 with a Swagger interface on the tenant, and that is the route for incidents, requests, problems, changes, tasks, knowledge, users, teams, configuration items and the journal records underneath them. It is the first question on the first call, because every decision below depends on the answer.
-
Then
Build the crosswalk and agree the mapping
Cherwell record IDs and public IDs map to ServiceNow sys_ids in a crosswalk that every later load joins against. Incident and Service Request are frequently merged or customized in Cherwell and have to be separated. Status and State resolve to a single ServiceNow state per client, which is a matrix somebody has to decide rather than infer. Journal rich text gets stripped rather than dumped into work notes as raw markup.
-
Then
Load in dependency order, with history intact
Users and groups, then configuration items through the identification and reconciliation engine with their relationships, then the catalog, then tickets by type, then journals, and attachments last, one file per request. The transforms are built to suppress business rules and notifications and to preserve original created and updated dates, so that moving history does not email your customers, restart SLA clocks, or stamp every record with today.
-
Finally
Reconcile before you cut over, not after
Source count, staging count and target count tied out per object, every variance categorized and signed off, attachment bytes checksummed, and sampled records compared side by side. Rehearse the whole sequence in a sub-production instance, then run the delta and cut over once. The delta keys on last-modified time, which is the only incremental field worth relying on.
What does not come across, and you should hear it now
One-Steps, forms, dashboards, email listeners, approval workflows, the catalog structure, SLA definitions and historical SLA timers do not migrate. They are rebuilt in ServiceNow. Anyone who tells you otherwise is selling you a surprise for month three.
The practical consequence is about history rather than effort: closed tickets keep their dates and their journals, but the SLA clocks that ran against them do not come with them. If your reporting depends on historical SLA attainment, that is a conversation to have in week one, not a discovery in week ten.
How much history moves is also a decision rather than a default. Five to fifteen years is typical. Open tickets plus an agreed window is the usual shape, with the rest archived.
What tends to go wrong
Treating history as a technical problem. The argument is never really about whether ten years of closed tickets can move. It is about whether they should, and who is allowed to say no. Settle that in week four and the build is straightforward.
Discovering the customisations during the build. Long-lived instances accumulate things that were never documented and are load-bearing anyway. Finding them while writing the pipeline is what turns a ninety-day plan into a hundred and fifty day one.
Rehearsing with sample data. A load that works on a thousand records tells you almost nothing about one that has to work on a million. The rehearsal has to run at real volume or it is not a rehearsal.
Leaving reconciliation until afterwards. If you cannot prove record by record that everything arrived, you will spend the first month after go-live arguing about it instead of running your service desk.
Where we fit
We do ServiceNow migrations and consolidations, principal-led. That means one senior engineer who owns the work rather than a three-role project team with a partner on the cover, and it is the reason the remaining window is workable rather than optimistic.
Being straight about what those are, because this page is about Cherwell and neither of them is: one moved fifty million records between two ServiceNow instances in a single weekend cutover with none lost, and one took an entire support operation off three legacy systems into one instance against a fixed go-live date. The case studies have the numbers.
We have not done a Cherwell migration. The honest version is that the method above is the same one pointed at a different source system, and what is specific to Cherwell is the extract and the mapping rather than the shape of the work. If you would rather hire someone who has done your exact source before, that is a reasonable thing to want and we will say so on the first call.
What we offer is to plan and run the migration with you: the extract, the mapping, the load, the reconciliation and the cutover, alongside whoever knows your Cherwell instance best.
If your Cherwell instance is small and tidy, you may not need us at all, and we will tell you that on the first call rather than after a discovery engagement.
Tell us what you are running and what date you are working against. We are booking Q4 2026 for cutovers that have to land before 31 December, and Q1 2027 for teams planning the move now who will run it after the deadline, which means covering the gap between end of support and cutover.
Book a 20 minute scoping call. If you would rather not use a form, email info@finite-partners.com or call (919) 230-8242.