In general, migrating to Reserved Instance follows the same set of steps as an on-premises migration between v5 and v10 as described in the
v5 to v10 Migration runbook although some of the steps will be carried out by the API Connect team on your behalf. The gateways deployed as part of the API Connect Reserved are APIGW only so the migration process below includes the porting of APIs to run on the new API Gateway without a need for compatibility mode and there is also no support for migrating Analytics data or visualisations.
If you are migrating from your own v5 deployment (e.g. on-prem), then you will be able to carry out all the steps yourself, although we can guide you via a support case if needed. For migrations from v5 Reserved Instance or Public Cloud the flow is as follows:
Provision API Connect Reserved Instance v10 through the IBM CloudIf you have not already purchased Reserved Instance, you can purchase this through your sales contact. You will then be provided with a provisioning code so that you can select the region and deploy your reserved instance through the IBM Cloud console. Provisioning is normally completed in a few hours once kicked off.
Initiate the migration process with a support caseThis will start the conversation with the API Connect team around migration and will be used for conversation and scheduling of any meetings required to discuss the process.
Extract v5 data and perform dry-run migration If migrating from v5 Public Cloud or Reserved Instance, this will be carried out by the API Connect team, who will extract the data from your existing API Connect deployment and run it through the API Connect Migration Utility to prepare, convert and push your data to your new v10 reserved instance. During this process there may be items highlighted that will need your assistance to adjust. This would normally take less than a week if no adjustments are necessary.
Verification and Testing After the dry run migration is complete it is crucial at this point to ensure everything is working as expected by running any test cases you have against the new reserved instance endpoints with existing subscriptions. This way any issues identified can be resolved without impacting the production APIs. The timeframe will depend how manual the testing is and will be greatly reduced if you have a mature API testing strategy.
Preparation and final migrationOnce everything is confirmed, it is time to plan a schedule for the final migration. This will consist of a window where no-one will be able to subscribe or change their subscription to the APIs so as to freeze the subscription state whilst they are migrated. A final snapshot of the data will then be taken and migrated across to the new reserved instance. Any test suites to verify the APIs migrated would be re-run to ensure everything continues to work as expected and then once confirmed the production traffic is routed to the new instance. This final migration would be carried out in close collaboration within a scheduled change window resulting in zero disruption to API callers.
#APIConnect