In this blog series, we’re doing a deep-dive into Data Center migration. If you’re just getting stuck in, take a look at part one where we explored the big benefits driving businesses to choose Data Center. Here in part two, we’ll help you get organised ahead of migrating – focusing on what you need to consider, how to plan for success, and how to kick-start the process.
For an in-depth look at best practices for planning, preparing, and testing your way to migration success, download our free ebook Demystifying Atlassian Data Center migration.
When faced with a Herculean business goal, like migrating your Atlassian software from Server to Data Center, the sheer volume of information and potential pitfalls can feel overwhelming. A systematic approach, methodical plan, and realistic idea about what you can and can’t achieve is vital (and the expertise and support of an experienced Atlassian Solution Partner won’t hurt either).
There is no ‘Plan B’
Once you’ve started migrating, you’re on a moving train with a clear destination. It’s why planning is so pertinent to the migration process. There are three key things you need to consider to make sure your ‘Plan A’ is all you need. These are:
- What do you want to migrate? – Figure out exactly what you want to move to Data Center (and what you definitely don’t).
- Does you instance need a tidy up? – Spring clean everything that makes the cut so it’s suitable for its intended destination.
- Can your infrastructure handle it? – Make sure your architecture is primed for the process.
Your needs, under the microscope
To migrate or not to migrate? That really is the question. Before you can make any moves towards migration, you need to know what you’re transferring to Data Center, why, and what you’re happy to leave behind or move to Cloud. This might take time, requiring consensus from multiple stakeholders, but the process will be more than worth it.
A full system audit will soon reveal what doesn’t need to be migrated, streamlining the process down the road and avoiding unnecessary work. It should also identify your existing infrastructure, how it’s governed, how much data there is, how complex it is, what customisations you require, and which add-on apps and integrations are an essential part of your workflow.
Clean up your act
Moving to Data Center means some things will need changing to fit in at their new home, helping to avoid scary surprises after migration takes place. Here are some questions to prompt your clean-up process. If you want a full walk-through of how to spring-clean your system, download the ebook.
- Is your database going to be different? Include data preparation plans to make sure everything formats correctly for your users.
- Will you need to merge login IDs for different systems?
- Are there any custom field conflicts, such as duplicate names or regional spellings?
- Do you have pesky unpublished workflows that could cause your merge to fail?
- Have you health-checked your source instances since any recent changes?
For your Data Center deployment to succeed, your infrastructure needs to be up to the task. Take time to consider the resources required by your current applications and where you’re heading next to determine how many nodes your new architecture will need. Don’t be short-sighted – look at usage patterns and rollout to see if you’ll need more resources in the near future.
We recommend sticking with what you know when it comes to selecting your Data Center servers and load balancers. For example, if your organisation already uses Microsoft Windows servers and databases and F5 load balancers, there’s no need to move unless there is existing momentum to make a change.
And you’ll need a shared database and file system for all your nodes to access too – we recommend NFS or CIFS. If you’re already using multi-node databases and resilient file systems, try to make the most of these. Or if you’d rather not build your own resilience, some public cloud services can provide this for you – we recommend AWS Relational Database Service and Elastic File System.
Pick the right approach: big bang or bite-sized?
At Adaptavist, we follow a well-proven blueprint when tasked with helping customers migrate and upgrade – part of this involves developing a detailed plan and timeline for the process to take place. There are two key approaches your organisation might take when migrating to Data Center – a phased approach, moving a certain number of projects at a time, or a big bang event that rips the plaster off in one foul swoop.
Let’s take a quick look at both:
Big bang approach
More suitable for small organisations with less complex instances, this all-in-one solution is highly efficient if swift migration is your top priority. While it doesn’t require as much coordination and is less likely to result in configuration issues, there is potential for significant downtime and business disruption while migration is taking place.
It’s more likely that a phased approach, whereby you migrate projects in bite-sized chunks, is more suitable for your business. On the outside, this might seem inefficient and slow, but there are a number of key advantages. By focusing your attention on small datasets and configuration issues, you’ll fine-tune your process as you go. And with fewer teams involved at any given time, there will be more resources to dedicate to user acceptance testing (UAT), not to mention avoiding downtime affecting all your users at once.
Failing to plan is planning to fail
If you’re relying on internal teams to carry out your migration, the whole process – including testing, refining the process, and then migrating – can take up to six months. With competing pulls on individuals’ time and possible skills gaps, it’s clear why a full-proof plan is essential, and even more obvious why so many businesses choose to migrate with the help of an Atlassian Solution Partner.
Migration to Data Center is not without its complexities, and careful preparation and due diligence are paramount. But, with Adaptavist’s skills and experience by your side, your migration might only take a matter of weeks.