Ask any CTO about their top priorities with a cloud migration, and we guarantee security will be on that list.
Overall, studies show that cloud is more secure than on-prem. But, as with anything in tech, security doesn’t happen by accident. It requires careful planning, attention, and understanding. This is especially true when you’re moving from an on-prem system that you’ve secured to a cloud system that has different security requirements and processes.
To help ensure your migration is as secure as possible, we enlisted the help of Paul Hecker, a senior consultant with Atlassian partner MajorKey Technologies. MajorKey is one of our Platinum Partners with Cloud Specialization. They’re particularly knowledgeable about security and have consulted on over 30 successful migrations.
With a long career in IT and four years laser-focused on Atlassian products, here’s what Hecker had to say about making sure that your migration is locked down tight:
1. Understand the scope of your migration (and give yourself enough time to do it securely)
With so many migrations under his belt, Hecker says one thing is for sure: it’s easy to underestimate the scope of migration the first time you do it. More than once, MajorKey has had an early conversation with a new client and found that they think there’s an easy button. Push it and voila! You are securely nestled in the cloud.
But the truth is more complicated. Some migrations are easy and straightforward – in fact, we recently heard about a migration that took only two hours! Other migrations, however, are complex and take a lot of planning and work to pull off, such as the combo migration-consolidation project MajorKey took on that brought a whopping 20 instances into one.
Before you set expectations with leadership about timelines and budgets, someone (whether they be in-house or an expert consultant) needs to take the time to understand the scope of your project – including the time and budget you need to get the technical tasks done and to make sure you haven’t left any security loose ends undone.
2. Analyze your stack
So, where does the scoping start? From a security perspective, the answer is a stack audit. Analyze your current stack and how you manage user access today. If you don’t understand how it works, you’re more likely to skip important changes pre-migration or miss security red flags. Which will mean what in the future?
3. Evaluate your users (yes, every single one)
Danger, Will Robinson! User migration can be a security minefield, according to Hecker. In fact, it’s the number one place where MajorKey notices companies taking security risks. That’s why it should also be the number one place where you slow down and pay attention.
This isn’t because user migration creates security risks. It’s because companies often don’t take the time to evaluate their user lists before migrating them over. So, inactive users, users with too much access, and users with too little access all get lifted off of server and dropped into the cloud, often leaving openings for a breach.
The answer to this risky move is to evaluate your users individually and change their access before you move.
Some users may need less access. Still others may need more access to get unblocked from important tasks. And those that might be inactive can be retired altogether, closing up potential breach points (and saving you money since fewer users means less cost).
The bottom line is that too much access (e.g., inactive users or people with more rights than they need) is a security risk and too little access that keeps people out of systems that they need is a productivity risk. Taking the time to find that balance before your migration makes you more secure and more productive once you hit the cloud.
FYI
When we talk about retiring inactive users, we mean users who no longer need or use their Atlassian accounts but who still have active user accounts. This includes people who have left your company, changed roles, or otherwise no longer use the tools. The longer they have active user accounts, the longer you’re paying for them (and leaving them open for potential breaches). In most cases, those user accounts can be changed to inactive, removing the risk and the cost while keeping the record of that account in case you need it later.
The most successful companies not only evaluate their users and access levels but also take this opportunity to evaluate their policies on user access. Do people actually need the access levels they have? Why? What happens if they don’t have them? This is the time to explore, question, and update your processes – documenting, supporting, and communicating the new process clearly and widely once it’s updated.
And as a bonus? These companies save significant money in the process. MajorKey has seen customers save big by taking people who haven’t been active in years and switching them to inactive before migration.
4. Know your data
What do you manage? How do you protect it? What’s in place to keep your data safe?
If your data is a mess on server, it’s going to be a mess when you move to the cloud, which is why this is another place where you should pause and evaluate before you make the leap. You need to understand your existing user management and data setup work, how the business works as a whole (not just for the person you’re speaking to at the moment), and how data management will change in the cloud.
5. Document and assess your controls and processes
In Hecker’s experience, it’s common to find that the controls and processes that are supposed to protect our data and users aren’t very well documented. Pre-migration is the perfect time to remedy this problem – evaluate the controls in place and document what they are now, and any changes you plan to make in the cloud.
Start by digging into the business reasons for each control or process. Sometimes the reasoning is sound and the process can stay as is. Sometimes it’s a choice that made sense at the time and no longer does (because technology has evolved or other processes have changed, necessitating a change to this one as well). And sometimes a problem just needs to be solved quickly, and now is our chance to beef up security with a better solution. Identifying those last two scenarios gives you the opportunity to improve not only security, but also productivity, ways of working, and often, employee satisfaction.
Once you know which processes and controls need a second look, it’s time to ask some hard questions. Are there disconnects between how something is supposed to work and how it actually works? Are there processes and controls that can be improved to fill potential weak spots before you go cloud-first? Where are the security risks in your processes and controls – and how can they improve?
For example, you might find that you have a lot of dead logins, which offers more opportunities for unauthorized access to your systems. Or you may find that your dev instance and customer instance refer to each other, which can be a problem because things might go live before you’re ready. You might also find that some things are set to public when you don’t want them to be public (good news on this one: the Atlassian Migration Assistants will flag this for you!).
Once you’ve assessed your controls and processes and feel confident that they are what you want them to be in the cloud, make sure to document them thoroughly – everything from password policies to tech safeguards.
PROTIP
Check out our in-depth migration guide for more security and process tips!
6. Understand your regulatory responsibilities
Are you subject to HIPAA? Do you have intellectual property you need to protect? Are there audit requirements that you need to make sure you’re set up for?
Understand your requirements before you migrate in order to make appropriate decisions about what and how to migrate and where you may need a hybrid setup temporarily.
7. Take advantage of Atlassian Access
Atlassian Access allows you to connect Cloud to your existing identity provider – you can find the list of accepted identity providers here. This means there’s no operational learning curve for your user management experience (you manage users just like you always have!). That’s one less thing for your admins to learn and worry about and one more step toward a secure migration.
And if your identity provider isn’t listed, there are other options available. You can still connect your IDP with our APIs as we follow the standard SCIM protocol for user provisioning. Or, Okta has a connector for on-prem IDPs to connect to Atlassian Cloud. And if you’re only using Okta for Access, Okta is free!
8. Think about the big picture
Migration is about looking towards the future. Digital transformation, cloud, and remote work are accelerating and more important than ever before. And companies that don’t make the leap are already falling behind.
But it’s not enough just to migrate. Real, long-term business wins come from big-picture thinking – not only about what you need to do today to keep up, not only about what is (and isn’t) working for you now, but also about what will continue working for you for five years, 10 years, 20 years, and beyond.
The more you can prioritize long-term solutions now (even if they take longer and cost more), the bigger you’ll win long-term.
9. Find the right partner
While you certainly can tackle a migration yourself, it’s impossible to know what you don’t know. That’s why we recommend evaluating whether you should bring on a partner, especially if your migration is a complex one.
An experienced partner with a strong security background can help you identify gaps and steps you wouldn’t recognize yourself.
For example, the way that Jira refers to user accounts is subtly different between Server and Cloud. Similarly, on Server, you can have one email account with multiple accounts attached to it. But in Cloud, it’s 1:1. And when you migrate your calendar, colors and icons might change. When you know all of this up-front, you can account for it, set expectations, and plan properly for the changes you’ll face.
If you do plan to bring on a partner, look for one (like MajorKey) that understands how important the pre-planning above is. If a partner says you should just move everything as-is, run. They’re not thinking about your security.
You also want a partner who is transparent and gives you clear information and solutions, but doesn’t try to dictate solutions without input. And while a partner can help, we’ve found the real key to success (partner or not) is having strong buy-in throughout the organization. The better your engagement level, the smoother your migration.
10. Schedule regular health checks
Finally, migration is a chance to evaluate, update, and improve security (among other things), but it’s not the only time you should do so.
Regular access checks, process checks, and regulatory checks should be built into your schedules for the future. You don’t want to be far along before you find that you have 100 inactive users with active accounts that waste money and leave openings for potential breaches. Or worse, you discover that you have a breach because you didn’t schedule regular check-ins.
TL;DR: The secret to security success is your pre-migration process
One of the biggest risks to your security during a migration is not cleaning up and not taking the time to prep up-front. The goal should always be to find the balance between protecting your data and giving people the access they need to do their work.
While you can do this cleanup once you’re in the cloud, the more secure option is to do it before those dead users, accidental live pages, and other security risks transfer to a live cloud instance.
In Hecker’s experience, the most successful customers start this process early and go through their users and processes with a fine-tooth comb before migrating. In fact, in one of MajorKey’s most complex migrations of all time (a massive consolidation/migration of 20+ cloud sites and several user sites into a single instance), they watched in delight as their customer fully engaged with the pre-migration prep process and knocked their expectations out of the park. Despite being one of the biggest projects that Hecker has ever done, the project began and ended on schedule while minimizing security risks.
That’s a pretty big win, and it all came down to pre-planning.
If you’re planning your own migration, check out Atlassian’s Cloud Migration Center and MajorKey’s solution services.