There is always a point during an Atlassian Data Center to Cloud migration when someone says “while we're at it, let's fix everything”. Honestly, it makes sense. If you are already spending the money, disrupting the business, and asking users to adopt a new platform, why not clean up old workflows, custom fields, and move to a more standard way of working?
On paper, it looks really efficient. In practice, it’s often where migrations get in trouble. It’s not that transformation is a bad idea, the issue is timing. What I’ve seen work best is to transform before a migration or after it. Be very very cautious of doing both at the same time.
The biggest challenge of transforming during a migration is not the technical complexity, it is trying to figure out the issue when something doesn’t seem quite right. On one large transformation we worked on, the timeline kept expanding because there were multiple changes at once. Some processes had been redesigned. Some configurations had been changed to prepare for migration. And, of course, the move to Cloud introduced its own differences in functionality and user experience.
This created three overlapping sources of change:
- Transformation - the organization intentionally changed configurations to support a new way of working
- Migration - change because of moving data and configuration
- Platform - Atlassian Cloud is different than Atlassian Data Center
To the project team, those are three very different things. To users, they often look exactly the same: “This isn’t how it used to work.” And that is where things start to go sideways. A user reports that a workflow no longer behaves the way they expect. Is it a migration defect? A deliberate process change? A difference in Cloud functionality? Or simply something the user has not seen before? Instead of resolving the issue, the team first has to figure out what kind of issue it is.
UAT starts turning into a design review. Requirements that were supposedly settled get reopened. Defects become debates about intended behavior. Decisions get escalated because no one is quite sure whether the system is wrong or just different. That is the real reason sequencing matters!
A migration already introduces enough change to test, validate, communicate, and support. If you layer transformation on top of it at the same time, you blur the line between what broke, what changed by design, and what is simply different in Cloud.
The case for transforming before...
If the primary goal of the program is reducing technical debt, transforming before the migration can make sense. Make the changes in Data Center production first. Simplify workflows. Retire unused customizations. Standardize configurations. Clean up what you already know you do not want to carry forward and then let the environment settle.
Users have time to adjust to the new process while they are still working on a familiar platform. The project team can identify problems with the transformation independently of the migration.
Then, when migration starts, you are moving a known baseline.
There is also a practical economic argument here: if you already know a customization, workflow, or process needs to disappear, there is little value in spending migration effort recreating it in Cloud. Do not pay to move a mess you already know you want to clean up.
The case for transforming after…
There are plenty of programs where the opposite sequence is the better fit. Maybe the Data Center licensing deadline is approaching. Maybe infrastructure or security commitments require a faster transition. Maybe the migration window simply does not leave room for meaningful redesign beforehand.
In those cases, migrate first.
Move the organization to Cloud with as little unnecessary process change as possible. Let users learn the new interface, understand the differences, and get their footing. Then begin transformation as a deliberate fast follow.
There is another benefit here: you can design the future state around what Cloud actually makes possible, rather than rebuilding assumptions inherited from Data Center. Instead of asking, “How do we reproduce what we had?” the organization can ask, “Now that we are here, how should this actually work?” That is a much better starting point for transformation.
Objections?
“But we don’t want users to migrate twice”. This is probably the most common objection to sequencing. Leaders worry that changing the process before or after migration means asking users to go through two separate disruptions. But combining those disruptions does not necessarily make things easier. It often makes them harder.
When everything changes at once, users have no anchor. The interface is different. The workflow is different. Permissions may be different. Automations behave differently. A familiar process may have disappeared entirely. From the user’s perspective, it becomes one large, hard-to-understand event.
Sequenced change creates smaller learning curves that users can understand, “The process changed, but the tool is still familiar,” or, “The tool changed, but the way I work is largely the same.” Then, once that change becomes familiar, you can introduce the next one.
In my experience, that separation makes adoption easier, support more effective, and user feedback much more useful.
Before or after, how to decide…
The sequencing decision doesn’t need to be complicated. If licensing, infrastructure, or timeline pressure is driving the program, migrate first and transform afterward. If technical debt and process improvement are the primary drivers, transform first, stabilize, and then migrate.
There will always be exceptions, and sometimes there are changes you simply cannot avoid making during migration. But the principle is still worth protecting:
Transform before. Transform after. Be very cautious about transforming during.
The next time someone says, “While we’re at it, why don’t we fix this too?” the right response may simply be: “Absolutely. Let’s decide whether that change belongs before the migration or after it.”
If your team is planning a Data Center to Cloud migration and weighing when to tackle process changes, we'd love to talk. Praecipio helps organizations sequence migration and transformation correctly, so users aren't left guessing what changed and why.
This blog was written by Ashley McNeal, Director of Professional Services at Praecipio.
