Do you use Atlassian Server Products and Live Under a Rock?
Unless you’ve been living under a rock – you must know that your Atlassian Server products are about to reach their licensed Support End of Life on February 15 of next year. That’s only 11 months from now. Your Atlassian Server’s licenses, add-on licenses and depending on the add-ons you use, some of their functionality might cease as well.
Many Atlassian Solution Partners, and non-partnered Solution Providers, have released dozens of blog articles, white papers, and even clever social media posts in attempts to get your attention to get migrated. Some play on your fears of the unknown to get you to sign while others oversimplify the process with promises that it will be easy to move everything to your new destination in just a few weeks.
This article isn’t about the migration process but rather what you need to consider when selecting a vendor and what to expect from your own organizations as well. Think of us as your Sherpas as you prepare to tackle Everest. Take a deep breath and prepare yourself because this migration is going to be anything but “easy”, but we’ll get you there.
Experience Matters Most
Your internal IT resources are not equipped to attempt this on their own
Your employees are good at what they already know. Don’t ask them to attempt something they’ve never done before that’s so critical to your organization’s operations just to save a buck. In the end, you’ll likely spend more money paying your internal people to come up to speed, attempt it multiple times, and then finally have to pay a vendor to fix what got broken and then finally do the migration.
Fun fact, a substantial percentage of our past customers have come to us after they allowed their internal staff to attempt the migration on their own, often times making a big mess, corrupting or losing data, and/or ultimately turning their employees against the product suite.
Best Practice – Use employees for day to day tasks. Use vendors for 1-off’s
We like to joke that we’ve seen and experienced so much that we know more of what NOT to do than what TO do. Think of us as having the map to the mine field. Asking your internal staff to do something new to them is like walking through that mine field using trial and error as their plan. We already know where not to step.
In the end, choosing a vendor with experience on MANY different migration projects matters more than experience with just your own instance. Even different Jira projects with the same instance requires slight variations in how things are handled. There is no script to train your staff on tactics that have taken us years to learn.
Over the past year, 90% of our Project Services time was spent completing migrations. One could say it’s all we’ve really been doing for the past three years. You do what you do best, and hire out for the heavy lifting.
If a vendor says it’s “easy” or they make it sound too good to be true, it is.
Be skeptical of articles from vendors who make the process sound “easy”. If it was, you should be able to do it all by yourself. Most articles might not say it’s easy, but they imply it by only presenting you with a few options without considering your needs, wants, or compliance for that matter. Migrating your server to cloud isn’t a “one size fits all”.
Best Practice – Trust those who take the time to know you first…
In reality, until a person lays eyes on your instance(s) and spends at least a few hours getting to know you, gather some data, look at your logs, speak to your administrators and users, and discuss all of your options with you, no one really knows your unique situation and you shouldn’t take their advice, promises, or quotes.
High Order Solutions has migrated dozens of instances with hundreds of projects, thousands of Confluence spaces & pages, and countless numbers of Bitbucket repositories. One thing we’ve learned since being in business since 2013 is that not one migration went exactly like the others. Sure, Atlassian’s built-in cloud migration tool is great but there are lots of things you need to get right before the migration tool can do its thing correctly. Even then there are no guarantees that everything will go smoothly the first time. It’s at these times you need someone who’s seen and handled many difficult migrations.
Plan Your Work, Work Your Plan
Best Practice – Get a Project Roadmap from your Vendor
And make sure it’s detailed.
A great roadmap includes discovery time, deliverables, identified risks and mitigations, identified opportunities and implementation plans, and duration estimates with deadlines.
No detail usually means no experience.
Additionally, if the roadmap is built with a phased approach, you’ll not only see how to make the vendor’s schedule work with your employees schedules, you’ll be able to measure the vendor’s progress at a glance. So many of our customers were previously won over by the Vendor’s A-Team but got stuck with the C- or D-Team that didn’t know what they were doing.
Practice Makes Perfect
Best Practice – All migrations need a perfected, tried and true “script” before attempting the final cut over
Your vendor should insist you allow them to create a Sandbox – a clone of your production environment, that they can experiment with, make updates, roll-back changes when necessary, and get your power users to test everything is working properly. Most of our customer instances were so far out of date we had to perform many upgrades and clean-ups before attempting to migrate them to the Cloud or to DC.
Best Practice – A good migration includes improvements, standardizations, and streamlining
A messy instance is more difficult to migrate than one that’s tidied up and stripped of the things you don’t want migrated in the first place.
Standardizing project schemes, workflows, and customizations before your migration may even make the migration run more smoothly because there are fewer different “moving parts” that need different solutions. Making improvements or streamlining your instances, with functionality sign-off from your employees, also guarantees things are working as expected before AND after the migration.
Recently, a customer of ours reached out to complain that certain functionality stopped working after they were migrated to the cloud. In the end, we had to spin their old server back up to show them that functionality hadn’t worked in years. We still fixed their automation and made additional improvements they were excited to take advantage of. Now we make sure to test everything is working, even those features most of the staff don’t know they have.
How to identify inexperienced vendors
Best Practice – Beware the vendors who don’t consider the impact a migration will have on your employees
Change is hard, even when it’s necessary or supported by the majority of your staff. And if you don’t include them in the process, while finding ways to improve things as you go, you may as well tell them we’re changing for the sake of change.
A lateral (change) without advancing is worse than not making a change at all because you’ve gained nothing but risked everything.
No one product suite is perfect, including Atlassian’s. Most just tell their employees to take the bad with the good and keep on working. Well now’s the opportunity to get your user’s feedback on what works for them, what doesn’t work, what add-ons they use, along with those they don’t and build a plan around their needs that gives them something positive to look forward to after the migration. Even if you can’t incorporate all of their recommendations, you’ve involved them. Involved employees are less likely to sabotage something they’re invested in. And who knows, you may find their ideas could save your company money, increase productivity, or Both!
Best Practice – Beware the vendor who is quick to say “No”. It usually means they should have said “I don’t know.”
We’ve had several clients tell us that they were told by the previous vendor that “it can’t be done”, or “it’s just easier to start fresh with a clean slate”, or “your instance has a complex set-up, we can’t migrate any custom data”.
Again, any migration that leaves your employees with anything short of what they’re already used to is basically asking them to learn a new tool.
If you’re migrating from Server to Cloud and your vendor doesn’t offer user training, lunch & learns, what’s new articles, etc. your employees will be faced with a different look & feel, work processes they aren’t unaccustomed to, and most if not all of their custom processes removed.
Best Practice – Beware the vendor whose only focus is the migration
If you’ve ever had your car battery replaced at the dealership only to find later that they didn’t bother to clean the corrosion off the connectors or remove the leaves from the battery tray you know what I’m talking about. The best time to take care of whatever’s been put off or needs tidying up is when the hood is already up.
The same holds true for your migration vendor. Even though there’s always room for improvement not all companies are ready to make those investments at this time. That said all companies should know of broken functionality and once informed are usually willing to pay for those fixes to ensure the best chance for a successful migration. We’ve heard horror stories from companies who were told after the fact, by their migration vendors, that “some data was not able to be migrated” claiming they were not responsible for moving unlicensed add-on data or custom field data that kept the migration from completing. In the end, the decision to abandon old data or archived projects is the customers to make, not the vendors.
Experience matters. With Atlassian cloud migrations, specific experience truly makes the difference between a smooth, phased transitions and work stoppages, lost data, and frustrated IT staff. Choosing to engage a specialist is an investment that will directly benefit your business and employees. The decision process may have seemed overwhelming. In contrast, the best practices presented here provide you the tools to make an informed confident decision.