The Evolution of Cloud Migrations
The Rise of xCMA

So, with all the alternate options covered in our previous articles, what about the xCMA line of products?  As previously mentioned, JCMA was released with significant marketing back in 2020, but for people around me at least, cynicism was rife.  With the very large Cloud migration mentioned previously still ongoing, itself dealing with most of the difficulties that a JCMA migration even could be going through, and with Krisz's direct feedback from working with Atlassian still ringing loud, we knew this tool had a long way still to go.

This all said, the development of the xCMA tools continued, albeit at what felt like a leisurely pace given the looming Server EoL.  In JCMA, automated support for Plugin-App migrations was released in 2021, as was Jira Service Management support.  In mid-2023, Atlassian finally added whole-site migrations with JCMA, allowing an alternate option to the Project-by-Project option that existed alone up to this point.

These enhancements along with countless others trickled through quite slowly, all while we were right in the middle of complex migrations, spurred on by timeline limitations and the customers' expectations themselves driven by marketing promises from Atlassian.  Even when enhancements did come, the reality of the situation sometimes soured the reward.

The Plugin-App migration release was (and remains) a particular challenge - the tool requires vendors themselves to ship ETL processes for migration into their own products, which are called by JCMA during a migration, and vendor support was inconsistent at best.  With a big red "not compatible" mark next to their products causing marketing issues, implementation of App migration scripts became effectively mandatory.  With an ETL process not even being viable for many products, due to the stark differences between the Plugins v2 and the Atlassian Connect worlds, approaches taken by vendors varied significantly.

ScriptRunner is actually a great example of this - code written for ScriptRunner behind-the-firewall would typically include numerous calls to Java APIs, which is fundamentally incompatible with the Jira Cloud platform.  As said before, having a migration path was becoming mandatory, so with ScriptRunner at least, the solution was to migrate all the code in a commented-out state, leaving the end-user to rebuild their own equivalent on the Cloud from scratch.  This didn't necessarily align to a lot of users' expectations of what the end result of a JCMA migration should look like, and oftentimes the Support teams and the Consultants leading engagements bore the brunt of that frustration.

With these frustrations and challenges in mind, it's not surprising that Site Export / Import remained standard operating procedure for many migrations in the early 2020s.  From Atlassian's perspective, however, this was problematic.  The Site Import feature in Cloud was creaking by this point as mentioned previously, and in late 2021, they made a decision - Site Import would be phased out on the Cloud.

Between February and May of 2022, Atlassian started phasing out the availability of Site Import in Jira Cloud for sub-1,000 user migrations[^3.5.1], and by late 2023 the functionality would be removed entirely from the product[^3.5.2].  The addition of full-site migrations (as opposed to Project-by-Project) did help with this transition, but it still ended up being a hard transition for many teams, with a lot of long-planned migrations limping across the line in late 2023 just prior to Site Import's deprecation.

By early 2024, it felt like there weren't really any other options to support a Jira Cloud Migration other than JCMA.  CSV would miss your change history putting it (rightly or wrongly) out of consideration for many teams.  Carving your own JSON-based ETL using the REST endpoints would technically be possible by this point, but the cost barrier was too high to be taken seriously.  Other than that, there wasn't anything else on the market - teams performing migrations, and Atlassian Consultancies supporting those teams, needed to focus their efforts on JCMA.

The xCMA products have continued to incrementally improve over the years, and vendor support for Plugin-App migration is getting better.  With options seemingly limited, and with the xCMA line working well enough, the Atlassian Consultancy market switched gears and began focusing heavily on this path to the Cloud.

¹Atlassian's original announcement of the sub-1000 user phase out

²Atlassian's original announcement of the complete discontinuation of Site Import

The word "Standard" in the section heading above really does exemplify the approach being taken by the Atlassian Consultancy industry today.  Across the board, efforts are being made to standardise, simplify, and automate as much of the process of Cloud Migrations as possible.

This is not being done blindly - just after the Server EoL announcement the sheer scale of requests for support with Cloud Migrations was astronomical.  In order to satisfy the demand, teams needed to be able to do more migrations, more quickly than ever before.  Staffing levels rose and many Atlassian Consultancies, due to the relatively small number of experienced Atlassian Consultants on the market, brought in less experienced Atlassian Administrators or more general IT or Engineering staff without direct Consultancy experience, to train up and support these migrations.

Standardisation didn't just apply to the actual migration process itself - most Atlassian Consultancies were also standardising their estimation procedures used in presales, building automated tools to cost things, and in some cases providing a low-effort tool to get a quote and pay straight from the website without needing a direct technical discussion.

With this level of standardisation happening across the industry, a level of commoditisation began to occur - with a runbook-based process, direct experience became less important in the whole, and with contact time between Consultancy and customer being reduced, location became less of an issue for many as well.  Cost started to become the deciding factor for many customers, as the services being offered by different Atlassian Consultancies became less and less distinguishable from one another.

As time went on following the announcement, approaches became more and more standardised, and xCMA tooling became better and better out of the box.  The level of technical skill required to perform these migrations reduced, and we began to get to the point where more and more small customers - where much of the original volume had come from - felt sufficiently empowered to approach the problem themselves.  Belts began to tighten at many Atlassian Consultancies after the initial rush, and with margins becoming thinner and thinner due to the ongoing price war, a different type of resourcing decision had to be made by many businesses.

More traditional services that had been delivered by Atlassian Consultancies in the past (such as Plugin-based customisation, Java tuning, and database diving) were disappearing in the Cloud.  Although Cloud Migrations themselves were slowing, they still remained a large portion of engagements.  With financial pressures across the industry growing, legacy Consulting teams based in more expensive areas of the world started to become a big red mark in the P&L.  With new teams in lower-cost regions having been trained, and perfectly capable of following the runbooks and managing Cloud Migrations, the decisions that had to be made were obvious.

Today, if you're in the market for a Cloud Migration, most Atlassian Consultancies will focus on the price to deliver.  Some larger Consultancies might front an engagement with a local experienced Consultant as team lead, but in the majority of cases, most of the actual work will be performed by lower-cost teams in order to reach the competitive price point necessary.

To be clear, as much as I fear that I may be presenting this section with something of a negative tone¹, the reality is that every step made was entirely logical, and with the same assumptions in mind of an xCMA-driven future for the industry, I would have made the same decisions myself.

The fundamental problem that I have comes from the assumptions made here - that the xCMA migration path is either the best or the only route forward.  This assumption works for the majority of Server instances that were out there - predominantly smaller and less complex platforms than their Data Center counterparts.  As size or complexity increases, the number of manual fixes and tweaks required to keep data aligned scales more than linearly².  Compounding this is the fact that, in an xCMA migration, we are crowbarring data into a completely different platform, that in a greenfield world you would build in a completely different way.  As such, the larger or more complex your instance is, the more likely you'll be dealing with inconsistencies in your target system post-migration.

With Data Center coming up to End of Life in a few years, the instances targeting migration today are typically large and/or complex, and the cracks in the Cloud Migration market are starting to show.

At Echidna Solutions, we believe there is a better path, one that takes advantage of all of the tools at our disposal, alongside our years of Consultancy experience, to provide a faster, safer, and better path to the Cloud.

¹As an experienced legacy Consultant myself, I've obviously got strong feelings on this matter!

²For example, the effort required in manually resolving problems with each App scales linearly with the amount of data, causing n² complexity.  Furthermore, as integrations and automations become more complex, they begin to run into cliff edges of viability of implementation in the Cloud, causing massive jumps in the amount of manual re-implementations necessary.

After 3 parts, our groundwork has been laid, and as the reader you should feel that you have a good baseline understanding of the current state of the Cloud Migration market, and how it came to be where it is.

In our next part, The Echidna Approach, we will be detailing the process used by Echidna Solutions to perform Cloud Migrations that can be more cost-effective, faster, and safer than the traditional xCMA approach, all while producing a platform built for the Cloud.

The Echidna Approach will be released on Thursday 19th March 2026.