Redirecting page links from server to cloud after migration?

[Scott Cantor]

I think the answer is "no", but that seems insane, so I have to ask...is there a reliable way to do link rewrites to connect old bookmarks from the old site to the new?

It looks like the Cloud version of Confluence uses a different format for page URLs than server did, and embeds the page ID in the URL. So instead of /spacekey/topic for most ASCII pages, you end up with /spacekey/<number>/pages/topic

That seems to make setting up a simple rewrite rule from the old server to the cloud impossible since the page numbers are obviously all different and vary by page.

I can't imagine this isn't a core requirement for doing a migration. What am I missing?

[Brant Schroeder · Accepted solution]

@Scott Cantor 

Most people will just redirect all pages to the main Confluence URL.  I know some individuals that have done redirects for each page but added them manually which takes a lot of time.  There is nothing that can generate the redirects for you.

[Scott Cantor]

I appreciate the response. There is an API usable to get the new page IDs by topic, and from there it's relatively easy to generate a flat file and use it as a rewrite table in Apache.

So if anybody else comes across this, there is a way.

[Nikolas Gehbauer]

H @Scott Cantor ,

I'm looking for the API Endpoint that helps me with this topic. Since I'm migrating a customer that has a huge amount of external links (weblinks) to his confluence server.

kind regards

[Scott Cantor]

We have not as of yet relocated the script we used. If we can find it, I'll reply. I would just say that the API is likely one that just returns all of the pages in a space. That info structure for the pages contains the topic IDs and the topic Names.

[NCSU Libraries Information Technology Department]

For reverence the  API endpoint to use is /rest/api/space/<SPACEKEY>/content?start=0&limit=9999&type=page
I  wrote a simple, but embarrassing script to take that and dump them into separate files based on the key, then another to grab all the pageIDs and pageTITLES to make what I hope will become a rewrite map.

[eric_gagnon_banq]

Late to the party...

It's a bit hidden here and there and things have likely evolved over time but it seems like the migration tool generate a mapping data file (have not seen it yet so I dont know if it is a mapping using title or if the mapping actually contains the target migrated page id).

See here: https://jira.atlassian.com/browse/MIG-507

It means that there will be a need to host the redirect long term but at least it's possible to do so.

I would guess that tiny link are not adressed by that part of the solution.

Some info here:

- https://confluence.atlassian.com/confkb/the-differences-between-various-url-formats-for-a-confluence-page-278692715.html

- https://confluence.atlassian.com/confkb/how-to-programmatically-generate-the-tiny-link-of-a-confluence-page-956713432.html

[Darryl Lee]

Stay tuned - I'm working on an article addressing this very thing.

Well, it doesn't use the mapping file from Atlassian, that's new (4 days ago!), but I've got some good info, Apache/NGINX configs, and Perl scripts to generate your own mapping files (including for tiny links).

Fun stuff!

[eric_gagnon_banq]

Nice, Will keep an eye on this.

I didn't even realised the mapping file support was such a recent thing.

I'm not the one handling the migration (external consultant is doing the work) but I was trying to get a better understanding of the process, tools, risks and issues and make sure the plan is solid and complete and that we doesnt end with more broken links and "Former user" than we need to,

[eric_gagnon_banq]

@Darryl Lee This is the article you where working on, right?

https://community.atlassian.com/t5/Atlassian-Migration-Program/Don-t-Let-Your-Users-End-up-in-a-Dead-End/ba-p/2508545

I will give it a read, thanks!

[Darryl Lee]

OH MAN sorry I forgot to come back here and plug it. Yes @eric_gagnon_banq that's the one. 

[eric_gagnon_banq]

No trouble!

I did a first read and the only question I would have is considering the recent "mapping file from Atlassian" migration tool is what could guide decision on using one or the other approach?

Maybe it's a late solution for those that have completed the migration already? Or the mapping file doesnt provide solution for tinylink?

Someone else is working on the migration, I'll try to see if I can get a sample of the mapping file generated by migration tool and see if I can figure this out.

Thanks again!