Hi Integration Aspriants,

Recently I did my first CI Migration from NEO to CF. I would like to share my expeirence on the same. This blog will help you understand what will be the approach, challenges, solutions as well as timelines for such migration.

NEO vs CF Environment

SAP Cloud Platform provides two types of development environments : Cloud Foundry and NEO. Below table illustrates some of the differences between the two

Why move from NEO to CF?

• SAP has provided a much detailed explanation here.
• SAP has been following principles of openness and freedom of choice, SAP has been advising customers and partners for moving to multi-cloud environments.
• SAP has already confirmed that all new enhancements and services will be made available for multi-cloud environments only.
• For new customers, SAP has been providing licenses for CF only.
• For more FAQ please refer to the blogs FAQ-1 and FAQ-2.

Migration Process

Your Migration Journey will comprise of 4 phases which are accurately documented by SAP :

Migration Guide

• Discover

  • During the Discover phase it is recommended that you first be aware of the list of integration, security parameters as well as role setup in the existing migration.
  • Prepare a list of all Integration IFlow, and identify where changes will be required to be made once the artifacts are moved.
  • In both environments, Cloud Integration comprises – with a few exceptions the same features for Integration Developers.
  • For any such exceptions, see SAP Note 2752867.
  • Moreover, please go through the guide Environment-Specific Aspects Integration Developers Should Know. 

• Prepare

  • • Now that you have all the details of changes to be done during your migration you can start preparing your own roadmap.
    • Make sure that all artifacts in NEO are saved as a version not in draft mode else automatic migration will not work.
    • Once your plan is prepared, start communicating with related third parties and explain to them about the changes needed to be made so the Interface will run smoothly after migration.
    • You can start onboarding your new tenant. Here is the quick guide.
    • Download the compressed file found in note 2937549. This file contains the postman collection for migration.
    • Set Up an Oauth in both NEO ( for NEO make sure you generate Oauth on “tmn” node ) and CF ( For CF make sure the plan selected is “api” ) as per steps mentioned in the blog.
    • If you have to Migrate Certificate-to-User Mappings please refer to the guide as they are handled differently.
    • Next step is to start filling your environment file which you have downloaded from note 2937549. This is illustrated here.
    • You can also refer to the blog again for more detailed instructions.
    • For scrPlatformOauthID and srcPlatformOauthSecret please follow the below instructions( This is not illustrated in any blog):
      • • Go to your sub account in the BTP Cockpit for NEO Environment.
        • Navigate to Security >> Oauth
        • Go to Platform API
          

• • • • • Click on Create API Client
          
        • Select All Services
          
        • Hit Save
        • Note down Oauth Client ID and Client Secret for API Platform.
          

• Migration

  • Once you have the environment file ready, you are ready to start migrating the objects. 
  • First try to run, CPI MIG010 Connect to Tenants this will fetch the Oauth and XSRF token from both the source (NEO) and target (CF) Tenants.
  • If the above is successful then go for CPI MIG020 Readiness Checks API Runner, this verifies all design time artifacts are suitable for migration.
  • Next based on your design objects you can start migrating the objects, details are given here.
  • Things to remember during migration:
    • You need to provide PackageID in the migrate packages variable if you want only specific packages that need to be migrated. By default if it is empty all packages will be moved.
    • For migrating local variables only you need to use env variables varName and flowId. For global variables flowId will be empty.
    • When you provide a value for sourceHost, sourceTokenHost, targetTokenHost and targetHost parameters, make sure that the value contains only fully qualified domain name (FQDN) information without the https:// and alias.
    • Once User Credentials and OAuth2 Client Credentials are moved make sure to update password manually and deploy them again.
    • After custom IFlows are migrated, you need to deploy them again manually.

• Validate

  • Now that your migration is completed, for validation you need to create a ticket with SAP for most migration checks. More details are here.
  • Build a simple IFlow and test it to make sure the tenant is working properly.
  • Next, you need to start making the relevant changes in the source and target systems. Or ask the concern team to make the changes.
  • Once the changes are completed , one round of SIT is recommended.

Things to remember:

• As CF has two sets of IP (ingress and egress) , one needs to make sure they give a right IP for whitelisting for Inbound to CI and outbound to CI. Details here.
• For SCC Tunnel connectivity, tunnel IP needs to be whitelisted, which are given here.
• Environment file for the Postman Collection needs to be filled correctly.
• For production, you need to take a downtime of  3-4 hrs to make the switch from NEO to CF. You can move the artifacts early and keep them ready and share the details (new URLs and Authentication Objects) with the concerned team. During downtime, you can switch the Cloud Connector to the new production tenant and at the same time the concerned team will also make the changes at their end.

Challenges

• One challenge we faced was making the third party understand what they need to change and why they need to change? Typically this can be overcome by having a meeting with the third party team and explaining to them using Postman or SOAPUI tools on what will change.
• After migration, we faced an issue where the CF CI tenant is not able to connect with Cloud connector intermittently. Error was
  • SAP Recommended to install the latest version of SCC, but this did not resolve the issue.
  • Following blog will help if you face any cloud connector issue.
  • This issue is on the network side, I will update once it is permanently fixed.

Timelines

Typically migration timelines will depend on the number of third parties involved and total interfaces to be tested. In my case there were 2 third parties involved and we had around 20 interfaces, it took us 7 days to complete the migration and make the system ready for testing.

Below Activity table illustrates the list of activities can be taken as a reference by the project manager for migration purpose.