Don't migrate a workflow you don't like

A system change is the only time an organization will accept a review of its working methods without protest. Use it.

The most common mistake is rebuilding the old system in the new one, including the category structure with sixty options that no one fills out correctly and the eight priority levels where only three are used.

Fixing it costs about the same as moving it. The difference is that you won't have to live with it for another five years.

What should be reviewed along the way

The category structure. Look at the statistics: which categories are actually used? The rest can go.

The priority model. Is priority set based on impact and urgency, or on who is calling? See ITSM for how the model should look.

The service catalog. Start with the ten most common requests instead of moving everything over.

SLA. Are the current levels being met? If the answer is no, you should either change them or change your staffing – moving a promise you can't keep helps no one.

The change process. If all changes are urgent today, it is a sign that the process is being bypassed. Build it lighter this time.

What is being moved

Tickets and contacts. Open tickets in their entirety, closed history to the extent you choose. Two to three years is enough for most.

Assets and configuration data. Hardware, licenses, warranties, and dependencies – see CMDB and asset management. If the registry is outdated, it is better to rebuild it than to move the errors along with it.

Knowledge articles. Often the greatest need for cleanup. Articles that haven't been opened in two years likely describe systems you no longer have.

Service catalog and SLA. Definitions, approval workflows, and response times.

How it works

1. Mapping. The current state: processes, workflows, integrations, and what is working versus what is causing friction.

2. Configuration. Processes, service catalog, SLA, portal, and integrations with Microsoft 365, Entra ID, and monitoring.

3. Test migration. Data is moved to a test environment first.

4. Verification. You test against real-world scenarios. Do the technicians find the right information, does the escalation work, and are the reports useful?

5. Training. Technicians and administrators before the transition. Inform end-users about the new portal well in advance.

6. Go-live. Usually over a weekend, with the old portal remaining as a redirect for a period.

Where things usually go wrong

End-users are forgotten. Technicians are trained, but the hundreds of people who will use the portal are only told on Monday. This leads to an unnecessary spike in tickets.

Including everything. Ten years of history and a knowledge base that no one has cleaned up makes the migration expensive and the system sluggish.

Too many processes at once. Start with incident and request. Change, problem, and a full CMDB can come in step two.

No internal owner. Someone must be able to make decisions regarding categories and SLAs. Without that person, the project stalls.

Why us

In the field of ITSM, we are the Nordic region's most experienced and largest distributor and implementation partner for HaloITSM. We work in Swedish, Norwegian, Danish, and English within your time zone.

HaloITSM can be hosted within the EU, in your own cloud environment, or entirely on-premise, which is crucial for the public sector and regulated industries.