If the team is still chasing the same approvals after your ITSM migration, it's fair to ask what the move has achieved. The new system might be easier to manage, which is a useful improvement in itself. But if the purchase was meant to take routine work off the team, that part of the job is unfinished.
This gets awkward as the deadline approaches. Copying an existing workflow is something you can estimate and test. Changing it may mean getting an application owner to agree that their approval is no longer needed on every request. That conversation takes time, and it is much easier to put it off.
I don’t think “we’ll improve it after go-live” is enough here. It needs to be a funded piece of work with someone committed to doing it, or you should assume the old process is coming with you.
TLDR
Keep the parts of the service desk that work. Make time during the migration for the changes that justified buying the replacement, and give anything you defer a date and someone responsible for finishing it. Test the new process with the people who’ll use it and support it.
What Are You Willing to Carry Over?
If your team trusts the way privileged access is handled, there’s no obligation to redesign it just because the software is changing. They have enough to learn already, and the time spent rebuilding that process could go toward fixing something they actually want changed.
In Atlassian’s account of Clearwater Analytics’ move to the cloud, the company gained more automation while some employees were pleased their main processes hadn’t changed much. Both were useful outcomes. Those employees could get back to work with minimal changes to their workflows.
It’s harder to judge a process that works because someone keeps intervening. The approval is recorded in the ticket, but the chasing happens in Slack. Requests reach the right team because an analyst knows to ignore the assignment rule. The configuration you copy won’t show how much of this is going on.
Ask the analysts to walk through requests they’ve recently closed, including what they did outside the ticket. You may find the work you want to remove there: messages to get an approval moving, or information they had to look up because the form didn’t capture it.
Give those analysts time to help with the implementation. If they’re only available to explain the old setup, you can easily use up their contribution documenting work they hoped the migration would get rid of.
Who Can Agree to Change the Process?
Removing an approval sounds straightforward until you ask the application owner to sign off on it. From IT’s side, it may look like a delay on a request that gets approved every time. The owner may see it as their only opportunity to check who’s getting access.
The question is what they’re checking. If employees in a particular role are already entitled to the access, the owner may be able to approve that rule in advance and review the exceptions. If each request needs a decision about sensitive data or additional cost, that decision still needs to happen.
Previously approved tickets don’t settle this. They show what happened under the old process, including exceptions that may no longer be allowed. You need agreement on the current rule before building an automation around it.
You may also find that the policy is clear but the data isn’t good enough to use it. If eligibility depends on an employee’s role, and nobody trusts the role recorded in the directory, that problem needs fixing. Buying an ITSM platform doesn’t remove that dependency.
The analyst configuring the flow may have no authority over that data, let alone another team’s access policy. Someone leading the migration has to get the right people involved and make room for their work. Otherwise, you can have a finished workflow that nobody is willing to switch on.
If the directory cleanup has to wait, assign the work and agree when you’ll return to the workflow. It may be frustrating to keep the manual approval for now, but at least the team knows what’s preventing the change and who can resolve it.
Give People Something Familiar to Test
At Thinkific, one of the first automations built during the Ravenna proof of concept handled requests for higher Claude usage limits. Employees were asking for more credits as the company rolled out Claude, so this was work the IT team already had on its hands.
Kevin Vye, Thinkific’s Senior Director of Security, described seeing the automation solve those requests as the moment the value became clear. The team could evaluate it against work they already knew.
That helps when choosing your pilot. People who regularly handle the request can tell you where the new process is slower, where information is missing, and what they’ll have to do if it fails. Give them time to try their own requests, including the ones a demo is unlikely to cover.
Include the person who expects it to break. Ask them to try the requests they normally have to rescue. You want to know what happens when an approval doesn’t arrive, or when access is granted in one application but the rest of the workflow fails. The analyst taking over should be able to see what has happened without reconstructing it from scratch.
Watch how much checking the pilot creates, too. An analyst inspecting every automated result is still spending time on the request. Some checking is reasonable while you’re establishing confidence; agree what evidence would let the team stop, and include the ongoing checks in your estimate of the work saved.
If employees keep messaging an analyst directly, ask why. They may get an acknowledgement there and nothing useful from the new desk. More training on where to submit requests won’t fix that, so find out what they need before treating it as a failure to adopt the tool.
What Happens to the Work Already Open?
The employee waiting for access has already explained what they need and got their manager’s approval. A migration shouldn’t require them to do it again.
Decide where that request will finish before you switch over. It can stay in the old desk or move to the new one, as long as an analyst can find the approval and knows who is responsible for the next step. Don’t leave the employee to work out which system now owns their problem.
Reply to an old ticket email as part of testing. Check where it goes and whether the person receiving it can continue the existing request. A forwarding rule can deliver the message successfully while leaving the analyst without the history they need.
Rollback needs more thought once the new system has started doing work. AWS makes this distinction in its cutover guidance: returning to an unchanged source system is different from rolling back after new transactions. For a service desk, that includes changes made outside the ticketing tool.
Restoring yesterday’s database won’t remove access granted this morning. If a workflow makes an incorrect change, you need someone who can stop further execution and someone who can investigate what’s already happened. Agree who can do that before the launch, while you have time to test the recovery.
Once the new desk is running, go back to the requests you chose to improve. Ask the analysts what they still have to do, and look at how long employees are waiting. If the work you promised to remove is still there, keep that part of the implementation open and give the team time to finish it.
If you’re evaluating AI ITSM, we’re happy to work through one of those requests with you and show where Ravenna could help.
Frequently Asked Questions
Should Every Workflow Be Redesigned During an ITSM Migration?
Keep processes that already work unless there’s a reason to change them. Concentrate the redesign on the recurring work you bought the replacement to reduce, and include any policy decisions or data cleanup needed to make that happen.
How Long Should Both Service Desks Remain Available?
Let unfinished requests determine the overlap, with a clear cutoff for new work entering the old desk. Before retiring it, verify that remaining requests have been completed or handed over and that replies to old messages reach the right people.
Should You Move All Your Ticket History?
Keep the records needed for open work and your retention requirements, with an accessible archive where appropriate. Check the destination’s import limits before relying on migrated records for reporting; Zendesk, for example, says its metrics and SLAs aren’t supported for imported tickets.
