For IBM and IBM customers, 'change is the only constant'. We are continuously innovating and coming up with new offerings to meet the customers needs in the evolving market and at the same time, we are shutting down some services which are not relevant in current market due to factors like outdated technology, older security capabilities, better available alternatives etc. When we shutdown a service, typically we offer the customer a choice to migrate to one of our newer/better product(s) while also offering them a clear migration path.
This blog focuses on enabling easy migration for customers of classic IPsec VPN to VPN for VPC with minimal downtime and captures the following:
- Challenges customers face when choosing between the available options to migrate from the classic IPsec VPN
- Approach of migrating classic IPsec VPN customers to VPN for VPC + Transit Gateway (TGW) solution
- Motivations to move them to VPN for VPC solution which enables long term benefits for the customer.
I recommend reading the full blog to better understand the motivations and challenges, however if you are just interested in 'steps to migrate classic IPsec VPN customer to VPN for VPC with minimal downtime', a shorter version of this blog exists and the link for same can be found in the comment at bottom of the page.
The Migration Problem
One of the questions we frequently come across is 'how do we migrate our customers from Classic Infra to VPC'. But then, why do we need to migrate them at all? Here's a list of key motivations to migrate customers from classic to VPC:
- Customers get the benefit of highly scalable services built on modern technology like SDN while also offering better isolation and security.
- VPC services will see more innovation and are key to our medium to long term strategy.
- Classic services are slowly getting deprecated &
- Cost advantage.
However, more often than not, we see classic customers leaning towards continuing with the classic infra as long as possible. Typically because they don't want to disturb the working deployment which has stabilised over time. While in short term this works for the customer, they are just deferring the inevitable migration. The risk is they may end up in a situation where they just don't have enough time for migration of one (or possibly many products) and puts them in a difficult spot where they end up making costly mistakes.
This begs a question! 'How do we enable them move without impacting their existing deployments?' Let me walk you through a recent case where we just took first steps in this journey enabling the customer to make this move from classic IPsec VPN to VPN for VPC.
The Situation
We announced the deprecation of IBM classic IPsec VPN offering back in November. The service is scheduled for End of Service in June, 2025 and the customers using this service have option to migrate to
- VPN for VPC or
- Gateway Appliances
We've started receiving customer requests for migration and a specific customer reached out seeking help to move them to Gateway appliance. Acknowledging the request, we started evaluating it. A closer look into the customers consumption and architecture revealed the following about customer:
- Low monthly invoice amount (around 5K)
- Running an e-commerce service deployed on IBM classic infrastructure
Looking at the cost of the Gateway appliance relative to customers monthly invoice footprint, clearly the monthly cost for appliance was overwhelming for them and it didn't seem a good fit.
With the help of CSM, we reached out to the customer to understand if they had evaluated VPN for VPC for their needs. The customer came back suggesting that they did evaluate VPN for VPC however, their needs were not met with VPN for VPC. Intrigued as to what needs wouldn't be met and how big a pain it is that they would not choose a lower cost option; reached out to the customer again to probe further. This time the customer conveyed that the requirement for them to convert their accounts from non VRF to VRF to use VPC products is a major barrier for them due to:
- The downtime associated with non-VRF to VRF conversion
- IPsec VPN is not supported with the VRF accounts
- VPN for VPC is not supported with non VRF accounts.
These 3 factors essentially mean that the customer would need to:
- Delete existing instances of IPsec VPN
- Raise request for non VRF to VRF account conversion
- Once conversion is complete, they would need to configure the VPN for VPC instance and test it out
- If the tests are successful and the customer's on-prem applications can reach the classic VSIs hosted in IBM cloud classic, deploy configurations into production.
While this sounds a good plan for migrating these customers, there are limitations in this plan:
- The downtime would still be at least few hours (which was not suitable for customer as they are running an ecommerce portal)
- The whole migration process is irreversible i.e. they can't revert to IPsec VPN once the account is converted to VRF
#1 and #2 were key barriers for the customer. But allowing the customer to continue the path of Gateway appliances clearly had below problems:
- The monthly bill for appliances will always stick out like a sore thumb for them.
- They would almost never move to VPC.
The Solution
So, what is the solution? After few discussions with the IaaS Network dev & leadership, here's the multi-phased solution we came up:
Phase 1
- Customer configures an appliance (say Juniper vSRX) to begin with.
- After testing the appliance works fine, customer can proceed with deleting their IPsec instances
At this stage, customer has migrated from IPsec VPN and has their services running without any downtime required for the migration from IPsec VPN to Gateway Appliance.
Phase 2
- Now, Customer reaches out to support for non VRF to VRF conversion and fixes the date/time for this exercise.
- Support performs the conversion
- Once conversion is done, customers will restart services while still leveraging appliance to connect the op-prem to IBM cloud.
At the end of Phase 2, customer has their deployment still using Gateway appliance however now, they have their account migrated to VRF which enables them to start experimenting with VPN for VPC service.
Phase 3
- Customer configures the VPN for VPC + Transit Gateway based solution to connect on-prem to IBM cloud and tests the deployment.
- When successful connection is established, customer can just route their traffic to VPN for VPC.
- Delete the Gateway appliance.
Refer the below high level reference architecture diagram for a VPN for VPC + Transit Gateway solution.
With this multi-phased approach leveraging an appliance during the migration, downtime is limited only to the period where customer's account will be converted from non VRF to VRF.
The customer understood the value this proposal would bring to them and happily agreed!
Wrapping up
This is not about just migrating the customer from IPsec VPN to VPN for VPC. It is about helping them gradually transition from classic to VPC and not defer it till the last moment. It is about enabling them to get introduced to our VPC product line, to try their hands on the modern infrastructure services we are building on VPC. Post this migration, customer will be able to play around with our offering line available on VPC like Bare Metal Servers on VPC, Virtual Servers on VPC, Block Storage, Load Balancers, Private Path service etc. and when they see the value VPC offerings provide them, they will be willing to work with us to help them upgrade/migrate to VPC services.
To summarise, the real and lasting impact of this migration is that it'll opens the doors for adoption of modern, lower cost infra and help customer take the first step towards this eventual migration of our customers from Classic to the VPC infrastructure!
Special thanks to @Shaival Chokshi & @Sakthi Saravanan Shanmugam for helping solidify the approaches and establish the reference architecture that would enable this migration.
#iaas #vpn #vpnforvpc #migration #ipsec
------------------------------
Mukesh Kumar
Senior Product Manager, IaaS Networking.
------------------------------