Verifying the target system on Kubernetes, OpenShift, and Cloud Pak for Integration

Verify that the target system is in a healthy state and fully configured.

Before you begin

Complete Restoring the target system on Kubernetes, OpenShift, and Cloud Pak for Integration.

About this task

Check the health of the target system, complete any optional configuration, and validate data, APIs, and URLs.

Procedure

Use the health_check_post_migration.py script to health check the target system.

Examples:

When all the subsystems are in the same namespace, and the deployments uses username/password authentication:

python3 health_check_post_migration.py -s PLATFORM_API_HOSTNAME -r REALM_NAME -u USERNAME -p PASSWORD -n NAMESPACE

When all the subsystems are in the same namespace, and the deployments uses username/password authentication, with use of the optional flag -check_portal_site_health to check the health of Portal sites:
```
python3 health_check_post_migration.py -s PLATFORM_API_HOSTNAME -r REALM_NAME -u USERNAME -p PASSWORD  -n NAMESPACE -check_portal_site_health
```

When subsystems are present in different namespaces, and the deployment uses username/password authentication

python3 health_check_post_migration.py -s PLATFORM_API_HOSTNAME -r REALM_NAME -u USERNAME -p PASSWORD  -mgmt_ns NAMESPACE -gw_ns NAMESPACE

When all subsystems are in different namespaces, and the deployment uses username/password authentication:

python3 health_check_post_migration.py -s PLATFORM_API_HOSTNAME -r REALM_NAME -u USERNAME -p PASSWORD  -mgmt_ns NAMESPACE -gw_ns NAMESPACE -ptl_s NAMESPACE -a7s_ns NAMESPACE

When all subsystems are in the same namespace, and the deployment uses SSO authentication:
```
python3 health_check_post_migration.py -n NAMESPACE --sso -s PLATFORM_API_HOSTNAME
```

When all subsystems are in the same namespace, and the deployment uses SSO authentication silent mode:

python3 health_check_post_migration.py -n NAMESPACE --sso -s PLATFORM_API_HOSTNAME -api_key API_KEY_VALUE

When there are multiple subsystems across namespaces:

python3 health_check_post_migration.py -s PLATFORM_API_HOSTNAME -r REALM_NAME -u USERNAME -p PASSWORD -n "namespace1|namespace2|namespace3"

Complete any optional configuration steps needed for your deployment:
1. If necessary, update redirect URLS in the authorization server.
  
  If OIDC or SSO authentication is being used, the redirect URLS must be updated in the authorization server after migration. For example, for Google OIDC, you must to add the new redirect URLs in Google Developer Console. The new redirect URLs can be found in the user registry in Cloud Manager.
2. If necessary, complete configuration for Analytics.
  
  If the Analytics service is present on the target system, backups must be configured. Also, use the Cloud Manager UI to manually associate the Analytics with the Gateways, as needed.
3. If the target system is Cloud Pak for Integration, you must use the password from the target API Connect system to log in to Platform Navigator.
4. If necessary, update Portal and Gateway services names in scripts or utilities.
  
  The migrated Portal and Gateway services will have new names (old_name + "new"). Any scripts and utilities written using the apic toolkit must be updated if they are using names as input parameter and not the ids. This is applicable to only Portal and Gateway names.
Validate configuration data:
1. Validate the data in the target API Connect system by logging into Cloud Manager and API Manager UIs.
2. Validate the APIs published in the Gateways.
3. Validate the Portal site URLs
4. If necessary, update the DNS mapping info.
  
  Once all of the APIs are verified, you may need to update the DNS mapping info, to redirect the calls to the new Gateways and Portals.
The v10 migration is now complete.
After migration is finished, and verification of the target system is complete, you can uninstall API Connect on the source system.

See Uninstalling API Connect.