Agreeing with Tetiana on the core point: the Zendesk side of this is instance-level, so trying to run a half-and-half state will give you broken links. The integration only knows about one Jira endpoint at a time.
A few practical things if you're going phased on the Jira side:
Keep the Zendesk integration pointed at DC for the whole migration window, even as projects move to Cloud. Yes, that means new Zendesk tickets can't link to already-migrated Cloud projects during the transition, but it's the least painful option. The alternative (flipping the integration mid-migration) leaves you with a chunk of links that can't resolve in either direction.
When you do cut over, the link migration tool relies on issue keys being preserved across the move. Worth confirming with whoever's running the Jira side that they're maintaining keys for every project, not just the early ones. I've seen this trip people up where late-wave projects got new keys assigned and the link migration silently failed for those.
One thing to plan for: the link migration tool runs once per previously-connected instance and can take up to an hour. If your support team is actively linking tickets to Jira during business hours, schedule the cutover for a quiet window. The integration features keep working during the migration, but newly-created links during that hour can behave oddly.
If you've got the budget for it and the timeline is tight, third-party tools (Getint, Unito) handle project-level sync more flexibly because they're not constrained to Zendesk's single-instance model. Worth a look if running parallel for weeks isn't an option for you.
What's the rough scale, number of projects and active linked tickets? Right answer shifts a bit depending on volume.
For the process, we would simply link your Zendesk tickets and projects from the old Jira instance to the new one in any case they don't carry over once you have done the migration.