We are working on a requirement to migrate the Datapower services to App connect.

Currently we are doing transformation using XSLT and gateway scripts and these need to be migrated to App connect. I understand that this is going to be redevelopment, but wanted to check if there any best practices or references for this solution?

That's an interesting migration path - moving from DataPower to App Connect does involve a shift not just in tooling but in development approach, especially when it comes to XSLT and gateway script logic. In similar transitions, I've found it helpful to first modularize the existing scripts and transformations before mapping them into App Connect flows. This helps avoid one-to-one rewrites and instead encourages optimizing based on App Connect's native capabilities.

A useful parallel is how the Payslip App for Ghana transformed its backend logic from legacy systems to more streamlined, app-based architecture. The shift wasn't just technical - it improved security, accessibility, and performance, particularly for end-users accessing their salary data on mobile. Thinking along similar lines - user impact, maintainability, and future-proofing - might guide your App Connect migration more strategically.

I would think more appropriate migration would be from Data Power to API Connect. API Connect does come with some XSLT transformation capabilities. If you/your customer has Cloud Pak for Integration entitlement, API Connect is included in it.

You might want to consider how you intend to use ACE going forward, the microservices world is fast learning that it needs to orchestrate different services and therefore maintain state between them and so the merry go wheel is almost back to where it started in requiring an ESB. You have a number of options, you can utilise the XSLT, utilise the mapping nodes or write it in one of the languages such as ESQL. Consider how you would support this in a production environment too, the toolkit debugger is all well and good but you can't/shouldn't be using that in Production.

My choice would be the relevant transport nodes coupled with a compute and ESQL, it might seem like a sledgehammer to crack a nut, but a well architected ESB can see those services lifted of the shelf and utilised in-conjunction with other services in an orchestrated process.