Most migrations go wrong in the same order: people move the email first and then try to build the desk around live traffic. Do it the other way round.
Usually far less than people expect. Open tickets have to move or be finished in the old system. Closed ticket history almost never needs to - it is read once a quarter, and exporting it is available if anyone asks. Users, agents and knowledge base content are worth bringing.
Create your groups, agents and roles, your categories, your ticket statuses and your SLA policy with operating hours. Doing this while tickets are already landing means fixing configuration under pressure.
Agents and users can be created in bulk rather than one at a time. Get this done before go-live so nobody is waiting on an account.
Published articles are the one piece of content with immediate value - they start deflecting tickets from day one. Move your top twenty and leave the long tail.
Forward your support address to the portal only once the structure is in place and you have run a test ticket end to end. This is the switch, and everything else should be finished before you throw it.
Leave the old system readable but stop answering from it. Anything still arriving there tells you which integration or published address you missed.
Export whatever you are contractually required to keep, confirm your open tickets are all in the new system, then cancel. Cancel first and the export option goes with it.