Recently we have done a successful migration from the Neo to Cloud Foundry (CF) environment. In this blog, I will discuss our entire migration journey – what were the challenges we faced, our learnings, recommendations, and the key factors that resulted in smooth migration.

A competent architect (client’s) makes the migration easy. The same happened in our case as well. Someone who has been within the system for a long understands the integration pain points and always tries to optimize the same.

Documentation

As-is integrations can be understood through the existing documents. A lack of documentation may lead to an increase in efforts in system study.

A detailed integration tracker provided by the client was our life saviour. The tracker captured every single detail – sender, receiver, dependencies, scope, 3^rd party contact, etc.

Ongoing action item -> The team is expected to update the tracker. It helped to showcase deployment progress during Sterr Co. Meetings.

A detailed cut-over sheet acts as a playbook.

Suggestion – Try to leverage existing templates. Incorporate previous expertise templates (past projects). To track the overall project status, the team should update the development tracker placed centrally.

Identification of complexities – simple/medium/complex

Correct sizing of interfaces helped to forecast the efforts. Any 3^rd party tool can be used for such identification.

Remember, a few interfaces may fall into the group of sensitive processes such as audit compliance – SOX, GDPR. In our case client architect helped team in identifying sensitive processes.

Suggestion – The integration lead/architect should deep-dive to check for the level of complexity.

Right team on action and team sizing

A correct team structure is imperative for a smooth project transition. Considering a big project, quick upskilling of PI/PO technical resources on CI (Cloud Integration) can be a game changer.

A project manager is the captain of the ship assisted by an integration architect/lead.

A scrum master and a release master are like navigators of the ship for smooth sailing.

The integration architect and lead should raise red flags well in advance so that the PM and client architect can take necessary actions.

Suggestion – Organise knowledge-sharing sessions within the team to minimise re-work. In our case, the client architect conducted a few workshops on the functionality of the custom adapter.

Artifact migration from Neo to CF

For migrating iFlows from Neo to CF environment, SAP has given a set of POSTMAN collections. Using POSTMAN collections, the migration of packages can be automated.

 Ref link to download POSTMAN collection – https://me.sap.com/notes/2937549

 Ref SAP’s help document how to run the POSTMAN collection –  https://help.sap.com/docs/cloud-integration/sap-cloud-integration-migration-guide/migrating-cloud-integration-from-neo-environment-to-multi-cloud-foundation

Suggestion – Maintain proper version and comments, it will help during the migration of retro changes.

Note: security materials (certificates, Secure Parameter, OAuth2 Client Credentials, User Credentials, SSH Known Hosts) and PGP keys are to be maintained manually.

Connection setup

A few 3^rd parties might have to whitelist the IP ranges of the CF environment.

Ref. link to get the IP ranges based on your CF DC: https://help.sap.com/docs/btp/sap-business-technology-platform/regions-and-api-endpoints-available-for-cloud-foundry-environment

Share new endpoints of CI or APIM to 3^rd party with a new client ID and secret keys.

Suggestion – Check for the connectivity of SFTP, FTP, SCC, SMTP, etc. well in advance. Any unseen connection issues can be rectified at the beginning of the migration.

Development/migration (CI)

If any Neo environment variables are used inside Groovy scripts, then those need to be adjusted after migrating to CF (if applicable).

Take care of ongoing developments on the Neo environment as those need to be migrated to CF later (retro changes). Maintain a retro tracker for such cases for easy tracking.

Suggestion – Stick to the Neo production version number unless it’s a retro change. It will help during future tracking and audits. Do not miss to maintain the comments.

Development/migration (APIM) – If applicable

New endpoints of CF-APIM and secret keys to be shared with the API consumers; share the IP ranges of NEO for whitelisting (if any). Import certificates (if any).

Suggestion – Reuse of existing POSTMAN collections can save testing time. Connection tests can be done well in advance to check if Postman calls are successfully hitting the proxy endpoint. Try to stick to the same naming conventions of the security materials.

3^rd party adapters (if any)

In case any 3^rd party adapters are used like – Advantco to connect SFDC, Azure Blob, NO SQL, etc. to be configured again as the environment is changed from Neo to CF.

Check for the 3^rd adapter deployment on the new environment (CF) with necessary certificates (added in the known host).

A newer version of 3^rd party adapter might update the namespaces. It may impact the XPath. Compare the mapping results (Neo and CF).

Suggestion – Read the custom adapter documentation.

Unit testing & SIT

Leveraging 3^rd party tools like – IFTT INT4 can be used to compare complex message mapping logic (payload comparison of CF with Neo).

Suggestion – Capture test evidence as a testimony of successful migration. The same can be referred to later in case of any post-migration issues.

User acceptance testing and sign-off

The involvement of third-party integration partners is crucial for getting UAT signoff. Initiate communication well in advance.

To save testing time, try to use previous test cases. Testing tools (like HPQC or others) can be used to track the testing.

Suggestion – Being proactive and articulate eliminates most of the future unseen testing issues. Bring business to confidence as it’s a technical migration.

Production cut-over and go-live

A detailed cut-over template can ensure a successful production drop.

Cut-over playbook should contain – detailed sequential steps of execution, dependent steps, rollback plan, connection details, and contact details.

The release manager should share frequent updates with all the key stakeholders.

Suggestion – Discuss the cut-over sheet with the integration partners. Post-deployment monitor the integration run end-to-end.

Hypercare support and handover to support team

During KT – share the challenges faced during the migration and testing with the probable fixes so that the support team can function smoothly post-hypercare.

JMS queues (if any) are to be monitored for any huge piling up of failed messages as it may impact the overall performance of the tenant.

Share all the necessary documentation with the support team – e.g., test results, integration design, etc.

Suggestion – Discuss testing challenges/issues/bugs raised.

Recommendations:

Competent team – Right team on the ground is the key for any mission. Consultants should be flexible and proactive.

Daily standup call – To track the sprint progress.

Authentication – Replace BASIS auth with OAuth2.0. Minimise certificate-based authentication as it may require future support in case of the expiry of the certificates.

Communication – Communicate 3^rd party well in advance so that relevant testers can be aligned as per your project timelines. Suggestion – sample integration diagram to share during the initial call, with impacted systems, end-point changes (if any), new credentials, or certificate changes.

Tools – HPQC (for documenting test cases), MS-SP for documentation. IFTT @INT4 (for payload comparison), POSTMAN (for testing sending test payloads during connection tests – more relevant for APIM endpoint testing), CPI-Helper plugin @figaf for enabling trace from development window, CLDM @Integrtr (for logging business-critical messages to get 360 degree view of data).

Access – The migration team should not have developer access to – CF tenants and Neo prod tenants.

Inventory tracker – An inventory tracker should have all the necessary details Integration tab -> (package, interface name, group, subgroup, 3rd party details, channels used, dates, developer, status, etc.).

Credentials – Maintain credentials at a central place so that the development team can access them (password protected). Recommendation – Connection test to be done at the initial phase of the project to eliminate impact during SIT.

Key contacts – One of the crucial details with 100% accuracy – so that the development team can contact them during the SIT/UAT phase. Based on our experience UAT phase is going to consume most of the time. Lack of key contact may require constant follow-ups, resulting in an impact on the timelines.

Utilities – Development utilities can always add value to the existing arsenal. E.g., API’s to fetch message persistence (explore SAP Business Accelerator Hub), Adhoc integration flows to run as and when during production support in case of missing data, retrigger failed messages.

With this, we are end of the blog. By following the above information, you may sail smoothly through your migration journey from Neo to CF. Please share your experience.