Cloud Migrations as part of a Divestiture

[Luis Machado]

Hello everyone,

This past week I kicked off a project with a client that is divesting from its parent company and is wanting to migrate all of the projects, spaces, users, and associated data from Jira and Confluence into a greenfield cloud environment. We did a migration assessment with them some time ago to determine if migrating to the cloud was a viable option for them.

These projects have brought forth a unique set of challenges that have stemmed from the needs and goals of the two companies involved. I'm curious if anyone else has gone through a move like this and what challenges you had to overcome, or issues you faced as part of that process. I'll go first.

For this project, we have not been granted any access to the source instance which is owned by the parent company. All of our discovery, planning, and actual hands-on-keyboard for the migration process are being done via screen shares, exports, and screenshots. We were lucky in that the admin group has made great use of categories and keys to make it easy to identify which projects and spaces belong to the divesting company. But we're having to contend with cross-contamination of users, particularly in Confluence.

The source instances are pretty complex, with a large number of projects and spaces overall, heavy use of add-ons, custom scripting and reporting tools, pretty much the works. But it turns out the projects and spaces tied to my client are largely being used out of the box.

It's been interesting doing everything through a proxy, but the team from the parent company I'm working with has been really great so it helps. I would assume other people's experiences are potentially influenced by the relationship between the two entities and the circumstances surrounding the divestiture.

[Dave Liao]

@Luis Machado - Oy, I've been there.

Pondering what I'm able to safely share on here ha! 🤣

How much time do you have to complete the migration from the current tenant to the new one? As you know, that will inform on the discovery that is possible AND the time to execute on any actions identified.

If you haven't yet, maybe cross-post this to the Atlassian Migration Program area?

[Luis Machado]

It's a quick one... the client wants to be in and out in 2 weeks essentially, despite the recommendations we presented at the end of the assessment we did.

It will largely be an as-is migration, and we've communicated the risks associated with going forward in this manner. I was mostly just curious about what other folks have experienced in a situation like this.

[Dave Liao]

Yowza. Lots of luck to your team! 🍻

Hopefully all the stakeholders who'll care about the risks have seen the appropriate comms.

In situations where you're in-between a rock and a hard place, I try to present options to reduce pain (and the costs associated with each option) to allow teams to "brace for impact" in the best ways possible. 🤣

[Tom Lister]

Hi @Luis Machado 

I feel your pain. It's almost impossible to work this without admin access. But I'll share a similar experience and the 'dirty' solution we had to run with.

I was asked to onboard a business area from a subsidiary in a completely different timezone, from their Jira, which we had no admin access to, into out European AWS Jira DC.
This didn't go well, many war stories on this. We did eventually get a solution that onboarded their 160 projects.

The next crazyiness is that the sub then decided EU support for their timezone was unworkable. (That and the fact we expecting to be paid for hosting their work). We tried allowing them admin rights but after several tragic 'too many admin' incidents we were asked to migrate all the onboarded projects off to a new AWS based instance they could own.

Also in the mix here is that some users had worked in projects in both regions but each region used a different user domain. So we now also have lots of duplicate users with the same name but different emails.

So to the divesting ourselves of the subs recently onboarded projects...

We had no access to the target instance. It was being built by a local 3rd party employed by the sub. No-one wanted to buy tooling to migrate the projects. The 3rd party was requesting a complete physical backup of our system so they could tweak and install on their side. 
Quite mad but since I wasn't having to actually do the rebuild I wasn't concerned.

However we couldn't just hand over a complete copy of our Jira and Confluence as it contained a lot of business sensitive data that we weren't allowed to share.

The dirty solution, on our side, was...

• Create a complete backup of our prod jira and confluence, mail disabled
• Run scripts on this to remove all of our projects and spaces (fortunately we had good categories to work with)
• Export the cleaned system (file system, server images, complete DB) as a whole to the subs partner.
• Once the dust settled,  post migration, we ran a similar process in our prod to drop all off-boarded projects

To everyones surprise they did mange to bring up a working copy on the new servers.

Although this worked, both systems still contained a lot of 'junk'. i.e. although we dropped projects, this left behind hundreds of broken filters, references to users who were no longer part of our system, broken boards and dashboards. This wasn't an operational problem as no-one was aware of the carnage except the admins. It was weeks of background work searching and deletes objects.

When I came to perform a Cloud migration for the EU org this year, the above history came back to bite us big time. Fails on broken filters still referring to projects and users we thought we'd removed. Duplicates users from various attempts to resolve previous access issues.

We got the cloud migration done but it probably added an extra month of effort.

[Luis Machado]

What a wild ride, hats to you sir. Thanks for sharing!

[Dave Liao]

Now THAT is a story. Sending karma your way @Tom Lister !

[Jonathan V.]

Wow, thanks guys for sharing. This is eye-opening for me, as I am looking to migrate into the cloud, possibly away from our parent company on-prem install.

[Dave Liao]

@Jonathan V_ - good luck with whatever path you take!

Curious what's driving your interest in Cloud? (Hopefully you have a few Jira admins on your team 🙂)

[Jonathan V.]

Part of it is the end of support for server installations, as well as trying to minimize our infrastructure costs.

Unfortunately, for most things Jira, I am the admin. 

[Dave Liao]

@Jonathan V_ - I feel for you. 😅

[Dave Mathijs]

Thanks @Luis Machado for sharing your story and experiences. I feel for you, keep up the good work!