How To Plan a (Successful) MuleSoft VPN Migration (Part I)

You might need to migrate your MuleSoft legacy VPNs to Anypoint VPN. You might be changing your routing, from static to dynamic. Or maybe, you're moving to Cloudhub 2.0. It doesn't matter, you need to migrate your VPN. 

A VPN migration could be a complete nightmare, or it could be a great opportunity to improve your Mule setup. You decide. Many think the key to a good migration is to set up everything correctly. They're wrong. The key to any migration type (VPN, infra, apps... etc.) is to have a PLAN. A GOOD PLAN.

In the next couple of posts, we're going to list a good amount of topics that you should consider to create your VPN migration plan. Not all of them will be relevant to your case. For those not applying, it will be good to know that you've thought about them and that, fortunately, they don't apply and not because you didn't notice. 

Do Your Numbers

Ask yourself and your team:

• 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 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? Which ones would it be possible, with previous notice, to keep them disconnected? Creating different levels of impact and associating them with those levels will help you with your migration timelines
• If you have more than one connection to be migrated, are they independent? Meaning, do your apps use one or the other, do they use both? If they are independent, that means you could migrate one VPN connection and, after that, the second one. Your apps will be impacted once. If your apps use multiple VPN connections you need to decide:
  • If you migrate both VPN connections at the same time, your apps will also be impacted once. But the risk is higher, 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.
  • You decide. No one but you knows better your system and your users

Add more questions to this list if necessary. The goal is that you end up with enough info to design a timeline, how many phases you need, how many people you need to involve, and how much time you need for this. We can't have the same plan for migrating 10 or 10,000 apps.

Understand the Requirements and Limitations

Anypoint VPNs come with some requirements and some limitations. Don't worry, they are not very constraining, but not everything is possible. 

For example, do you know that there is a maximum of 10 VPN connections per VPC or a maximum of 95 entries in the routing table of a VPC? In terms of configurations, are you aware that Anypoint VPN does not support NAT, IPv6, or policy-based routing?

Make sure you read the full list of requirements and limitations in the official documentation. You don't want to proceed with your migration and find out your device is not compatible or that your routing is not supported. Planning all of this in the first place will save you a lot of time and effort.

Do Your VPCs Need Any Change?

Sometimes, I also found some customers, good customers, with a great level of knowledge of Mule. However, when they started they were new to this technology and did what they could in their first setup.

Some of them, when they created their VPCs, didn't really understand how IPs are allocated in Cloudhub 1.0. Normally, 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've got +65k IPs and they probably need 10% of that. And 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? Is it something doable or it will be just too much?

Your Environments

Are your current VPNs segregated by environment? Having the same VPN connection shared by production and non-production environments is a really bad idea. I don't think I've got to explain why, but for those who are still doing it, here are some examples of why:

• If you share the same connection, any of your production apps, by mistake, could start pulling non-production data and using it as production. Disaster
• If you share the same connection, any of your non-production apps might end up working with production data. Another disaster
• If you share the same connection, your non-production apps will be consuming and, therefore, the network bandwidth available for your production apps. What if your devs don't know about it and start doing performance tests with millions of requests in their non-prod apps?

And these are only 2-3 examples... not mentioning security implications. So, if that's your case and you're about to migrate your badly shared VPN, please don't take with you this huge problem to the new VPN connection.

Cloudhub 2.0

Perhaps you don't have to review all of the above related to VPCs, BGs, etc. Consider that maybe, instead of restructuring/redesigning your network architecture in Cloudhub 1.0, it's a good idea to do all of that directly on Cloudhub 2.0.

You probably know (and if not you should) that there's a new version of Cloudhub 2.0, with a whole new type of infrastructure behind the scenes. 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, and the CIDR blocks are calculated differently.

My recommendation is to take this into account, if you're migrating your VPNs that might be a good moment to do the migration to CH2.0. Think of the benefits of CH2.0, maybe you find that there are features and functionalities you could benefit from and could anticipate that migration.

Because there will be a migration to CH2.0. There's no official date for the End of Life of CH1.0 but, what I can't tell you is that one day CH1.0 will not be supported anymore and you'll have to migrate to CH2.0. That's 100%. So, think about it, if that's not too complex you could do your VPN migration as part of the CH2.0 migration and reduce impacts or downtimes. Just think when it would be a moment for that migration. Don't think you don't have to migrate.

In the next post we'll continue with more topics you should think about to plan a successful migration. Click here to go to the second part of this post.