Intranet migration without tears

Confluence to Notion. Old SharePoint to new SharePoint. Google Sites to SharePoint. Each switch has legitimate reasons — better features, lower cost, a cleaner tool stack.

What tends to get overlooked: the day after migration, every internal link is broken.

Every bookmark someone saved over months. Every link shared in a Slack message. Every link in an onboarding doc, an email signature, a Confluence page, a Jira description. All 404.

Why it hurts

Links are infrastructure nobody notices until everything breaks.

People can’t find anything. The first days after a migration are filled with “Where is…?” questions in Slack and Teams. IT gets flooded. Productivity drops for days, sometimes weeks.

Worse, the new system feels broken from day one. People had just started finding their way around the old one. Now they’re starting over, and their first experience is: “My bookmark doesn’t work.”

Some teams respond by building workarounds that never go away. A Google Doc with “important links in the new system.” A pinned Slack message. Exactly the kind of fragile hack the migration was supposed to eliminate.

What most teams do

Most teams set up redirects. That makes sense, but it has real limits.

You have to know and map every old URL. With hundreds of SharePoint pages, that’s a lot of work. Automated redirect mappings rarely catch everything.

Redirects are also temporary. When you shut down the old infrastructure, the redirects disappear with it.

And redirects only fix this migration, not the next one. The moment you switch tools again, the whole problem repeats.

A different approach: separate the name from the URL

Internal links point to URLs — technical addresses that change constantly. When a Notion page gets renamed, the URL changes. When a SharePoint folder gets moved, the URL changes. When the tool gets swapped out, the URL changes.

What shouldn’t change: the name people know a resource by. “Roadmap” stays “Roadmap” whether it lives in Confluence, Notion, or a Google Doc.

The fix is a layer between the name and the URL. A shortcut like short/roadmap points to the current location of the roadmap. When the URL changes, you update the shortcut once. Everyone using short/roadmap lands in the right place.

Simple enough. But almost nobody sets this up ahead of time, because the pain only shows up after the migration.

How to prepare for a migration

If you know a tool switch is coming (or even just possible), set this up now.

Start by finding your 20 to 30 most-used internal resources. These cause the most damage when their links break. Roadmap, wiki homepage, HR forms, onboarding docs, brand guidelines, architecture documentation. Ask the team which links they open daily or weekly.

Then create a shortcut with a readable name for each one. short/wiki, short/roadmap, short/onboarding, short/brand. Share them and get the team used to typing shortcuts instead of pasting raw URLs.

When migration day comes, update the URLs behind the shortcuts. The team barely notices. short/wiki used to point to Confluence, now it points to Notion. Same name. No broken bookmarks. No shared link in Slack leading to a dead end.

What this doesn’t cover

If someone pasted a direct Confluence link into a Jira ticket, that link still breaks after migration. Shortcuts only protect the links that were shared as shortcuts. The more your team uses shortcuts, the better you’re protected against migrations.

And shortcuts don’t do the actual migration work — content still needs to be transferred, reviewed, and adjusted. This is only about the navigation layer: making sure people can find things after they’ve been moved.

When to start

The best time to introduce shortcuts is before a migration. The second-best time is now, even if no migration is planned. Tool switches happen more often than you’d expect. And even without a migration, things change constantly: Notion pages get restructured, Google Drive folders get moved, someone renames a project.

Each small change breaks a link somewhere. Usually nobody notices right away. But eventually someone clicks a bookmark and lands nowhere.

Shortcuts absorb those changes quietly. You don’t notice them working until you realize nothing broke.