Fix links after cloud to cloud data copy

[Mac McCardle]

We're currently moving our many Confluence and Jira Cloud sites to a single site under our organisation's admin. I was wondering if anyone had a good solution for fixing broken links after a cloud-cloud data copy. 

Post-migration from server we could run a tool provided by Atlassian that would update the server URL's to their correct cloud counterparts - we'd love to do the same in cloud.

Our issue is as follows:

We've confluence and jira running on the source (acme-one.atlassian.net) and target (atlassian-two.atlassian.net) We've moved confluence from acme-one to acme-two. This means all our confluence assets are now on acme-two

Documentation created before the move on acme-two references acme-one, meaning users are misdirected to the wrong site. Likewise, links to confluence from Jira on acme-one also direct users to confluence on acme-one

As mentioned, this is already a tool for S2C migrations, would be great to know of our options for C2C

[Kristian Klima]

Hello @Mac McCardle and welcome

When exporting a space from Confluence Cloud One to to Confluence Cloud Two, the links within that single space should be preserved (updated). In other words, the links among the pages within Acme Two's links should work if they're proper 'Confluence' links.

Anyway....

To fix links, you can use a marketplace app like Link Management or something more sinister that allows you to search and replace strings such as Find and Replace.

[Mac McCardle]

Hey Kristian, cheers for the advice - you're correct that links within confluence are automatically updated. That is working as expected. 

We'll look into those marketplace addons, although in our organisation addons are a tricky business.

Failing that, we may just end up running a local script to query the API.

[Kristian Klima]

API is always an option :) 

One of the magic of Confluence is that 'there's an app for everything' and it can be installed and uninstalled again.

I wonder, though (independently of this case) whether the reluctance to install apps is a carry-over from Server days as you're not the first post-migration person to refer to the 'tricky business' of apps :)

[Mac McCardle]

For us there's two key barriers, Licensing and our own business rules & requirements.

Licensing is largely costs from having around 5500 users and the inflexibility of acquiring a license. If our needs change you're locked in to the license for the duration of your contract with Atlassian. We're currently paying for an app that wasn't able to deliver in cloud - but we agreed to it early in the project and thus are stuck with it for now.

There's no way to manage app access. If we only need the app for a small group of users, we have to pay for everyone to use it. The alternative is to silo those users and their data in another site, which sort of defeats the value of Confluence and leads to migration issues like we're having now. Additionally, you're looking at a cap of 200 users and having to pay for additional licenses for apps in use on the main site. 

In summary, licensing is an issue largely due to inflexibility of the current model

Our business rules require products to meet some requirements, especially around data processing, security and residency. Getting assurance is not easy and we also take on risk if the app developer chooses not to support the product, We've limited SLA or assurance from 3rd party app vendors. 

Another angle is that whilst we juggle the amazing benefits the app community offers and the barriers we experience, there's the performance issues in cloud, and risk that if we invest a lot of time into utilising a feature or tool - it could be withdrawn or rendered functionally destitute at any time. We just cannot justify building high value processes around a product that could be turned off at any time leaving us with thousands of hours invested into a dead end.

To summarise our own requirements - There are limited to no protections for our investment. We hold all the risk and none of the control.

I don't mean this to be a moan about app licensing and appreciate that our needs are specific to us, not the community. If you're running a smaller team, it's probably not an issue but for anyone in enterprise it's a real killer.

I hope to see improvements in app licensing, it would benefit all the devs out there and greatly improve Atlassian's revenue opportunities. 

[Kristian Klima]

@Mac McCardle Couldn't agree more, the current licensing model is often quoted as an obstacle, especially for apps that only benefit a specific (small) section of users, or utility apps that are important but are used once in a blue moon.

I heard on Team 24 that the licensing model will change but I don't have many details.

On the other hand... I was recently quoted $30K annually for a tech doc CMS... for 5 writing seats - only 5 people could actually write and edit. 

It had nothing that Confluence with apps wouldn't do, it had zero options for Jira integration, I'd still have to figure out (and paid for) an actual end-user public website, It had no SSO support, and although it had unlimited reviewer seats, the process itself was a major PITA.

[Mac McCardle]

@Kristian Klima we've received similar things to what was stated in Team24 from a few of our contacts and sources. Too early to say if it will be a perfect solution, but I think most users are excited for some new ideas in this space. 

I also appreciate how much Confluence can offer for the costs. It's good to remember how bad some niche products can be!