Many of us in the IBM community are exploring (or already undertaking) the journey from on-premises DataStage / Information Server environments to the new cloud-based options, DataStage as a Service (DSaaS) and the Watsonx Data Integration (WXDI) bundle.

I wanted to initiate a discussion to share experiences, best practices, and challenges related to this transition.

From our side, we have developed a structured modernisation approach that breaks down into phases:

• Discovery and Assessment – inventorying jobs, analysing dependencies, and prioritising a representative set for migration testing

• Environment Deployment – configuring DSaaS or WXDI in non-prod and production (with SAML, storage, and security models)

• Migration Planning – using workshops to finalise migration methods and dependencies

• Job Migration and Modernisation – migrating jobs in "T-shirt sizes" (for example, S about 200 jobs, M about 400, L about 600) while updating scripts, parameters, and resolving compilation issues

• Testing and Validation – unit testing migrated jobs, comparing outputs across environments, and securing sign-off

• Go Live Support – QA, dry run, cutover, and post go-live hypercare

Benefits we are seeing:

• Reduced risk with structured migration and thorough testing

• Faster time to value using agile delivery and parallel workstreams

• Enhanced capability through Watson Pipelines and orchestration features

• Future-proof, cloud-ready architecture

Questions for the community:

• For those who have migrated, what were the most significant technical challenges (for example, around job compilation, parameter sets, or dependencies)?

• How have you handled organisational challenges such as change management, security approvals, or aligning internal teams?

• Did you choose DSaaS only or the complete WXDI bundle, and what drove that choice?

• Any tips for testing strategies and sign-off criteria that worked well in practice?

• Looking back, what would you do differently?

I would love to hear stories, lessons learned, and any "gotchas" others can share to help the wider community approach this shift.

Hi Nigel,

I have worked with IBM on this topic from the start of the DaaS beta, we are currently in the process for migrating DataStage 11.7 to CP4D (which I guess is what you call WXDI) with a lot of support by IBM, we use a lot of different functionallity of  DataStage and some things are easier to migrate than others. Also some parts of CP4D have already been redesigned because of feedback IBM got (like changing the design of the Transformer stage, that now looks again more like in legacy, about this topic I have written a blog here).

Your aproach looks good, you just should keep in mind, that testing of the scope of your DataStage installation has to be done by you and will/can not be done by IBM, they themselves of course also test, but you have to

• Migrate your assets to a CP4D Testplatform and check if this works? Is everything importable? Maybe you use a stage with a parametrization, that IBM development had not on their radar. In some cases you may have to adjust the parametrization of the stage or talk with IBM to make it importable.
• Then check if what is imported successfully is runnable. There are more ways to use all the stages of DataStage "in the wild" than the developers in the IBM lab can think of, like e.g. nested subflows.
• Get rid of server jobs and basic routines before migrating. They are not supported in CP4D.
• If planing to go to DaaS instead of CP4D, keep in mind that not everything that is working in CP4D als works in DaaS, it e.g. does not support custom stages, build ops or send email.
• Watson pipelines are quite different to DataStage sequences, but I have not worked that much with them compared to flows. You should check if they work as you would expect them. Think about if you want to refrence your nodes my name or by id.
• Especially have a plan how to deal with each of your sources/targets, this is from what I can judge where in flows you will have the most difference to legacy. E.g. using connection by service name does not work anymore, but you have to connect by hostname and port (which is also possible in legacy but this has been introduce not that long ago, or JDBC connector does not support kerberos in CP4D and you have to go from jdbc connector to impala connector, there are no multvendor stages in CP4D like e.g. DRS Connector or the Stored Procedure stage, they will be migrated to something else. Think about if your staying with local connections or going to project connections, I would recommend project connections and doing the migration is a good point in time to switch. 

KR Ralf

------------------------------
Ralf Martin
Principal Consultant
infologistix GmbH
Bregenz
------------------------------