Hi Vasu,
Do you have an idea of what platform the v10 installation will run on?
VMWare, OCP or CP4I? I've done the migration on VMWare but finally settled for OCP so have learnt lessons along the way and do not mind sharing.
Our migration was relatively smooth as we had a good understanding of the landscape.
Things to consider:
- Make sure your all addresses for the Gateway, Portal, Manager and Analytics have DNS resolutions.
- If you are using OCP, try use Routes. This allows you to give addresses a "pretty" name.
- If you are using OCP, make sure you build your v10 environment using YAML files instead of the GUI. It makes future upgrades and managing changes a lot easier. Commit these YAML files to a repository - GIT or SVN etc
- Certificates - Have fresh certs signed and ready upfront.
- Endpoint changes. This is where you have an API calling an API. As the address changes, you may need to update the APIs back-end address.
- Firewall - consider opening your firewalls before you migrate.
- Do not use your organisations actual mail server for your first iterations of the migration. Use a 'dummy' mail server as there will be hundreds of mails that will be sent out to users. The IBM Knowledge Center does have this well documented. Do not overlook this step otherwise your v5 user base will be flooded with mails.
- LDAP or Active directory. Make sure you have firewalls and network routing in place before.
- Portal - If you have a custom theme on the v5 portal, it will not work on v10. (I stand to be corrected).
- Communication - make sure you communicate this migration event with all your internal or external consumers and users.
I setup a MS Teams channel and made that the central point of communication. It worked well.
- Weigh your options. For example, if the v5 environment only runs 5 APIs, is it really worth migrating 5 APIs onto v10?
Rather build v10 fresh through the lessons learnt from v5. then rebuild these 5 APIs on v10.
- Roles and permissions, the roles and permissions your users have on v will not accurately match those roles and permissions on v10. We had to redo our user roles and permissions. (I stand to be corrected on this as well as my migration was using the early versions of the AMU - 10.0.1.2-r3).
- Gateways? Will you be using the same v5 VMs or physical appliances for your v10 Gateway?
If so, then your migration may be a lot more complex and may drag out.
The physical DPs can be split into two by introducing a tenant. This does require a lot of work. Also make sure your DPs are on the same version as the API subsystems.
- Gateway Options? What Gateway option are you planning to migrate to? Native v10 using the DataPower API Gateway or the v5c using the DataPower Gateway. With all the time and effort you will be spending on this migration, I would strongly advise to spend a bit more time and migrate to the Native v10 Gateway instead of v5c? There are many benefits and is well documented on the KC.
- HA/DR - try build your v10 environment upfront with the HA/DR options. It is documented on the KC.
These are some of the the points that come to mind.
I have not read the migration documentation on the KC since we migrated over a year ago so not sure if there are new features or major updates now available.
Good luck.
------------------------------
Rosh
------------------------------
Original Message:
Sent: Wed October 26, 2022 11:10 AM
From: Vasu Yanamala
Subject: APIC Migration V5 to V10
Hi Rosh
Would you mind sharing some of the migration issues you have encountered ( if any) that needs to be corrected in V5 before migration. We are planning to migrate next year ,just want to prepare . Appreciate your response
Vasu
------------------------------
Vasu Yanamala
------------------------------
Original Message:
Sent: Wed October 26, 2022 04:23 AM
From: Rosh
Subject: APIC Migration V5 to V10
Hi Vasu,
Strictly speaking from my own experience..
There is no official checklist for the v5 to v10 migration as environments in each organisation is built and managed differently.
The most important part of this migration is having a deep understanding of the v5 environment.
You need to know it and what is running on it inside-out and backwards.
Some of the key hurdles:
- What are the back-ends for each and every API?
Reasoning: This is required as you may end up hosting your v10 environment on a public cloud platform using CP4I or API Connect directly.
- How many APIs use oAuth?
Reasoning: Need to know this as oAuth is setup a lot differently on v10. - What is your migration strategy, are you expecting to go with a "big bang" approach or run v5 and v10 in parallel??
Reasoning: Both these approaches have their pros and cons. The approach we went with was running both in parallel and giving consumers 6 months to switch to the new addresses. The approach caused least amount of impact to business. Downside of this is you need to chase every consumer to switch. - Clean up?
Reasoning: This migration is a good opportunity to cleanup the environment.
Delete unused APIs, rename or standardise names for TLS profiles. Rename Space, Catalog and Org names. With this migration there is so much more that can be achieved.
- Networking and firewalls?
Reasoning: Where will your v10 environment be hosted? You will need to consider firewall rules or network routing in case the architecture has changed. - Communication with external consumer?
Reasoning: Do you have external consumers of APIs? If so, how are you going to manage the transition of the public facing Portal site?
These are just some of the challenges we came across.
I'm sure the provided Migration Utility has come a long way since I've used it with v10.0.1.2-r3.
------------------------------
Rosh