The Echidna Approach
Creation and Summary

First of all, let me make it clear - my 12.5 years at Adaptavist were awesome, and the team is made up of genuinely world-class people - particularly in the Consulting department where I spent my time.  I entered the business as a green, young, keen 20-something Atlassian Admin, and worked alongside heavy hitters in the ecosystem such as Jamie Echlin, Nic Brough and Ravi Sagar.  I remember my child-like excitement when each of them joined the business¹, and my fervour in working alongside them.  Memories of those early days stick with me, like Jamie and I working together on a FedEx Day to build a Linear Programming based resource allocation tool for agile boards², our discussions which ended up forming the foundations of the "Script Fragments" functionality in ScriptRunner proper, or getting into the weeds on an international 5-instance merge project with Nic.

Halfway through my time at Adaptavist, I was offered a role as a Managing Consultant, running a team here in the UK, alongside my peers Nic Brough and Will Davies.  It was in this role - being responsible for presales, solution design, and the development and training of my team - that the first seeds of what has become the Echidna Approach really began to crystallise.

During my time at Adaptavist the world of Atlassian Consultancy changed enormously in relatively short order.  In 2012, much of the work that we would do was inherently technical, purely out of necessity.  During my first day on the job, I ended up neck-deep in SQL scripts in order to manually merge two Jira systems together!  During these early days, I would be writing custom Plugins, working with customer Infrastructure teams to perform platform build-outs, or digging into the inner workings of the JVM to solve performance issues.  The reality was, in 2012, the Atlassian tooling and the surrounding ecosystem were immature - instances needed heavy customisation to make them usable, tooling to support one-off events (like Project Configurator for merges) didn't yet exist, and performance of larger instances was less than ideal.

As Atlassian and the surrounding ecosystem evolved, so did the customers using the tools - as a Consulting team, we needed to keep up.  Work became less directly technical, and we started to focus a lot more on the business side of things³.  More focus was put into Agile methodologies, and scaling options for them.  Into areas such as Business Information tooling and processing (a passion of mine, coming from a Maths background).  Into working with teams up and down our customers' businesses, to help them extract real business value from their toolset.

My team and I embraced this new challenge - our focus shifting from "how do we fix this problem?" and "how do we implement this requested change?" to "how do we help these teams work better?" and "how can these tools support the users in their work?".  This was also enormously empowering to us as Consultants - instead of simply seeing the technical outcomes of our efforts, we were watching as teams became happier, more effective, and even as some switched from being staunch critics of the tools into their strongest advocates.

In the world of Cloud Migration, this shift started to happen near the start of the Era of Divergence.  Early on in this period, although Cloud Migrations were rare, when they did come up our standard approach of Site Export / Import would work well enough.  Over time, as the worlds of behind-the-firewall (BTF) and Cloud began to separate further from one another, things started to feel somewhat off.  Pre- and Post-Migration manual interventions were on the rise, and the resultant Cloud sites would feel somewhat weak and messy compared to greenfield implementations we'd done for others.  As new features were released in the Cloud, the gap only got larger, and we'd have to be on the lookout for even the most subtle of feature usage to ensure a good experience in the Cloud⁴.

With our approach having firmly shifted to Consultancy, conversations with customers became more complex and nuanced, which could easily put customers off when compared to the "easy" technical approaches of some of our competitors.  This became even more evident following the releases of the xCMA line of tooling, that (in marketing messaging at least) promised a one-click migration to the Cloud, but in reality retained most of the complexity of the Site Export / Import process.  Something had to change.

¹For Jamie and Nic in particular, it was much earlier in my career when they joined - I recall meeting Jamie for the first time at a pub local to our offices while the Adaptavist team were trying to coax him over from his role in the financial industry, and my surprise when first meeting Nic to find out we went to the same school as kids (although admittedly separated by a few years!).

²An idea which worked on paper, but which quickly became obvious would end up being a stick used to beat development teams - we never released it publicly!

³I would be remiss to not mention at this point my mentor across the more Business Consultancy areas of my work, Richard George, who was fundamental to my growth as a Consultant.

⁴My favourite example of these weird, subtle idiosyncrasies between BTF and Cloud comes in the way that Jira boards work in each platform.  In BTF systems, an Agile board is an independent object, which simply takes the result of a JQL filter and displays it within a new view.  In Cloud, a board remains, in essence, a view on the result of a JQL filter, but it's no longer independent - it's a child object of a single Jira Project.  For 80% of teams, this difference is meaningless  For that remaining 20% though, their entire configuration ends up broken.  In Jira, until recently at least, the closest analogue to a real-life "Team" was effectively a board, and to a real-life "Product" we have a Project.  In a customer that has multiple teams working across multiple products, the Cloud platform's configuration aligns each team to exactly one product.  This logic flows down many paths in the tool, and as a customer, you have to make a decision - is the team to board analogue wrong, is the product to Project analogue wrong, or is it just something to work around?

In around 2021, I started to advocate internally for a change in our messaging to customers - the Cloud is (by this point at least) a great platform, but the tooling is fundamentally different to their BTF cousins.  Instead of buying into the promises of a one-button migration that Atlassian promotes¹, customers should look at a Cloud Migration as a full replatforming exercise, as if you were moving between products from two different vendors.  To move from the idea of a technical lift-and-shift to a more strategy-focused migration plan.

When my team were directly involved in presales ourselves, and so were able to effectively communicate the bigger picture to customers, the message really did land very effectively.  In the UK at least, engagements began taking this more Consultative approach to migration, looking at building out Cloud platforms directly and handling data retention as an ETL problem.

With 20/20 hindsight, this messaging was never going to be fully successful at a large Consultancy however.  Lead generation would be tricky given the relative "simplicity" of both Atlassian's and of our competitors' messaging on the topic.  Even with leads, the presales process is expensive - requiring significant expertise to explain and navigate the approach, and manual construction of work plans and costings.  This was a far cry from the world of pricing calculators and standardised plans, typically being presented directly by sales teams in xCMA migrations.  Even if the sales process was handled, with dozens of Consulting teams across the world, all focused on different markets and with different skills, the sheer number of Cloud Migrations required meant that a runbook-based, repeatable process would always win out in the end.

As I said though, the approach was used, although never as fully as I had hoped.  Over multiple engagements both the sales approach and Strategic Migration methodology itself were further refined.

When I left Adaptavist in early 2025, Krisz and I formed Echidna Solutions - a boutique Consultancy firm that wouldn't have the same scaling challenges as we had in a larger business, and one where we would be able to take these ideas and run with them.

Our goal?  To bring the people and conversations back into Atlassian Consultancy.  To shift the focus away from straightforward technical replication and toward business continuity, Cloud-native implementation, and extracting business value.  To help our customers implement strategic change off the back of their migration, and end up with a platform that supports their work better than their source instance could.

In our first piece of work, with Rightmove, we took our opportunity - executing the Echidna Approach to great success.  As Rightmove's CIO, Slawek Streich, said in our case study:

We were facing a roadmap that felt heavy - expensive, slow, and requiring us to hire a contractor just to clean up the data first. Jamie offered a bespoke path: treat the Cloud as a fresh start. Instead of just running a migration tool, he engineered a solution that bypassed the cleanup entirely. We chose Echidna because they treated this as a strategic modernisation, not just a data move.

¹Although I note that Atlassian's marketing tends to be better at highlighting some of the real complexity today.

In essence, the philosophy behind the Echidna Approach is simple - focus on your goals, and work backwards to establish the best path to them.  There's obviously complexity hidden under the surface here, but the basic premise is not rocket science, and is a standard approach to problem solving in general: understand where you are now, understand where you want to be, and plot the path between those points given this information.

With this in mind, the Echidna Approach broadly takes a 4-phase approach to Cloud Migration:

One important point of note here is how these phases are weighted in comparison to a more traditional xCMA migration plan - particularly regarding the Discovery & Planning phase.  Typically around half of Echidna Solutions' effort for the entire migration process is expended here¹, compared to a process that in xCMA migrations will typically be performed automatically on extracted data, and often without Consultant expertise during the sales cycle.  Given that each migration using the Echidna Approach is a fundamentally bespoke endeavour, this may not be surprising!  This Consultancy-driven focus on early efforts ensures that plans are tight, expectations are aligned, and the implementation process itself can be as smooth as possible.

In the remainder of this section, now that we have discussed the origin and overarching approach that we use at Echidna Solutions, I will go into detail on how we actually approach each phase.  Given that this is an inherently bespoke implementation dependent on customer needs, there are some areas for which I am unable to provide a detailed runbook.  For Discovery & Planning, the phase that fundamentally defines the rest of the process, the approach is relatively fixed - we will be going through that in depth in our next part.  For implementation (i.e. Development through post-Production Support), the detail of the approach is highly variable based on customer needs - as such, I will be giving hints and guidelines for each phase as opposed to a detailed breakdown.

¹The ratio in elapsed time can be a lot more variable due to customer dependencies - things like user testing periods, migration scheduling, and document reviews.

We continue our exploration of the Echidna Approach in our next page - Discovery and Planning.