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, 3rd 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.
Correct sizing of interfaces helped to forecast the efforts. Any 3rd 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.
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.
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-in...
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.
A few 3rd 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-f...
Share new endpoints of CI or APIM to 3rd 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.
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.
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.
In case any 3rd 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 3rd adapter deployment on the new environment (CF) with necessary certificates (added in the known host).
A newer version of 3rd party adapter might update the namespaces. It may impact the XPath. Compare the mapping results (Neo and CF).
Suggestion – Read the custom adapter documentation.
Leveraging 3rd 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.
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.
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
7 | |
4 | |
4 | |
4 | |
4 | |
3 | |
3 | |
3 | |
2 | |
2 |