VPN migration can be difficult if not done correctly, but proper MuleSoft VPN migration is an opportunity to improve your Mule setup. Whether you’re changing your routing from static to dynamic or moving to CloudHub 2.0 or any reason in between, you’ll need to know how to migrate your VPN. To help you along the process, we’ll go over what you should know to create your VPN migration plan.
What questions should you ask when planning a VPN migration?
When beginning your VPN migration process, you need to ask relevant questions to set yourself up for success. Ask questions like:
- How many VPNs do we currently have? How many of them do we need to migrate?
- How many apps would be affected if the VPN connection they use is temporarily down?
- What’s the impact of not having a connection to those apps?
- Are all the apps equally important? Which ones are really critical? Are there any that can stay disconnected with previous notice?
- If you have more than one connection to migrate, are they independent? I.e. do your apps use one or the other, or do they use both? If they’re independent, you can migrate one VPN connection to start, then the second, and your apps will only be impacted once. If your apps use multiple VPN connections, you need to consider the following:
- If you migrate both VPN connections at the same time, your apps will be impacted once. But the risk is higher, and the more VPNs you change in parallel, the more chances something goes wrong.
- If you migrate one by one, you’ll have much more control over the process, but your apps will be impacted as many times as VPNs you migrate.
The goal of these questions and others you might think of is that you end up with enough information to design a timeline, discover how many phases you need, how many people you need to involve, and how much time you need for the migration. The same plan for a small migration won’t work for a larger one, so your plan needs to differ depending on the size of the planned migration.
Requirements and limitations for VPN migration
Anypoint VPNs have specific requirements and limitations, so it’s important to review the full list to ensure you’re well-prepared. Starting the migration process only to discover device incompatibilities or unsupported routing can be frustrating. Taking the time to verify these details in advance will help you avoid potential issues down the road.
Do your VPCs need any changes?
People occasionally miss critical information when initially setting up their VPCs. For first-timers, even skilled Mule users, there might be discrepancies in understanding information, like how IPs are allocated in CloudHub 1.0, which causes issues later on. In this instance, one of two things might have happened:
- They provided a small CIDR block and they’re running out of IPs, which means they will have to either create another VPC, or more VPNs and do extra work to make it compatible with the existing one. Or they will just create another VPC and migrate all the apps
- They provided a CIDR block too big, probably the biggest one, a /16. They have 65k+ IPs and they probably need a 10% of them. Now, their networking team is struggling with their internal network space. Their Mule apps and setup work perfectly fine but giving back all the IPs not in use by Mule will help the networking team
If you’re in one of the two cases, or similar, because you didn’t size properly your VPCs and now, for other reasons, you need to migrate your VPNs think about that. How much impact or disruption will recreating VPCs and moving apps add to your setup? It’s something doable or it will be just too much?
Environments
If your current VPNs are segregated by environment, having the same VPN connection shared by production and non-production environments can lead to issues. Some of these issues include:
- If you share the same connection, any of your production apps could mistakenly start pulling non-production data and using it as production.
- If you share the same connection, any of your non-production apps might end up working with production data.
- If you share the same connection, your non-production apps will be consuming, limiting the network bandwidth available for your production apps. This could risk your devs not knowing, and they might start doing performance tests with millions of requests in their non-prod apps.
CloudHub 2.0
CloudHub 2.0 has changed the architecture of many infrastructure and networking components. For example, you won’t be creating VPCs, you’ll be creating Private Spaces; plus, the CIDR blocks are calculated differently. If you’re already planning to migrate your VPNs, it’s logical to also migrate to CloudHub 2.0 simultaneously as CloudHub 1.0 will eventually reach its end of life cycle.
Architectural changes
Sometimes a migration could be as “simple” as replicating what you’ve got in another infrastructure, the traditional lift and shift. But in many cases, it’s a good idea to review your current setup and ask whether your current architecture is set up well, what changes would be beneficial to make, and have their been any changes to the infrastructure that might impact how the VPNs work. Some examples of changes could be:
- You created your VPN with Static routing because your device didn’t support BGP, but recently your new device supports it. Will you keep your static routes, or will you take the opportunity to improve your VPN setup?
- You created your VPNs to connect to a datacenter (on-prem or in the cloud). But recently, your organization has started to move some data sources to AWS. Will you just replicate the VPN connection as it is, or will you use this migration to start replacing this to-be-commissioned connection for an AWS Transit Gateway?
- You’re still in CloudHub 1.0 and haven’t migrated to CloudHub 2.0. Will you only migrate your VPNs now and migrate to CloudHub 2.0 later, potentially causing additional disruptions?
- You created your VPCs, and their VPNs in a child BG. After some time, organizational needs have changed, and you’ve had to create more VPCs and VPNs to support the parent BGs. Will you move that problem to your new infrastructure with the migration?
- You created your VPN with static routing, no High Availability. At the time, you didn’t have as many apps as you do now. While you may never have wanted to add a second connection or move to dynamic routing, now is the time to make changes since you’re migrating anyway.
- You created your VPNs a while ago. Hypothetically, you might learn that the process of upgrading VPNs has changed (again) and that it will impact your existing VPNs. Get ahead of this by remedying problems before more arise.
Design a back up plan
What’s your level of support in your contract? What’s your SLA? If something goes wrong, how long can it take to fix it? The best strategy to avoid problems is to assume there will be problems. So even if you design a great migration plan, plan for something to go wrong just in case. Being prepared for the worst prepares you for success.
- Create your rollback strategy: Decide what to do if this step fails. You need to define the plan to shut down the old VPN and start up the new one. You also need to define how to shut down the new one and get the old one back up again – if necessary.
- Measure the time it will take: Once you know how to roll back, measure how long it will take you to do it. That’s how you properly estimate the window of time you need for the migration. If you tell your users X hours of downtime expected, that’s not the time you need to create the new VPN and shut down the old one. That needs to be the time it will take you to migrate everything, check that it doesn’t work, and roll back to the old VPN.
- Test your rollback strategy: Make sure the first time you do a rollback is not the migration date.
Test your migration
Do you have all you need to test if your migration is working? Do you have the tools on both sides of the connection to guarantee the new VPN is working? You need to define what tests you need to find the right answers: pings, traceroute, nslookups – you name them, but make sure you know exactly what you need to see before telling your organization everything is working.
Document everything
To help your team remember everything, include the following in your documentation:
- The current state, the as-is architecture
- The future or desired state, the “to be” architecture
- The migration process and the configuration steps that need to be followed
- The required tests to validate whether the migration is a success
Develop a communication plan
As with every migration – especially if you know there will be downtime – keep your users informed. Plan ahead, and don’t just send an email saying tomorrow your system won’t work for an hour. Let people know in advance so there’s less confusion and worry when downtime occurs. As soon as you have a date in mind and a set time for downtime, send your notifications out to make sure you’ve covered all your bases.
Be clear on what’s going to happen during the whole migration process: what elements will and won’t work and how long everything will take. Be specific and as open as possible to mitigate additional stress for your users.
Migrations: A necessary step to improved workflows
Migrations of any type are often met with reluctance because they involve transitioning from a familiar, controlled environment to an unfamiliar one that may seem uncertain. However, this challenge arises primarily in the absence of a well-defined plan. While VPN migration can be complex if not executed properly, a carefully planned MuleSoft VPN migration presents a valuable opportunity to enhance and optimize your setup and put you on the path to future success.
