A folder of DataStage exports is a starting point for migration. To plan a working replacement, you also need to know what launches each job, which settings it receives, what external files it needs, and who can confirm its output. This checklist turns those separate pieces into an inventory that engineers and operations can use together.
1. Record the source and export method
Start with the DataStage version, deployment type, project, environment, export date, and person responsible. Keep production and development inventories separate. Jobs with matching names may have different designs or parameter values. Record a repository path or asset identifier alongside each name so that similarly named jobs remain distinguishable.
Export options depend on the source environment. IBM's InfoSphere Information Server 11.3 documentation describes Designer options for including dependent items, exporting designs with or without executables, and including routine source code. XML export contains designs without executables. Record the options actually used; a successful export does not prove that every required dependency was selected. See IBM's Designer export options.
For the newer deployment documented in Cloud Pak for Data 5.4, IBM describes downloading flows and dependencies such as connections, subflows, and parameter sets as ZIP files. That is a different export workflow. Use the documentation for your installed release and confirm the accepted format and options with your migration tool before collecting the full estate. See IBM's flow download documentation.
2. Inventory designs and reusable logic
Count assets by type and reconcile the counts with the repository listing for the agreed scope. Include these items where your estate uses them:
- Parallel and server jobs: design, stage types, input and output objects, and before-job or after-job actions.
- Sequences: called jobs, parameter assignments, conditions, loops, failure branches, and restart behavior.
- Shared containers and routines: definitions, available source, callers, and separately maintained libraries or scripts.
- Parameter sets: definitions, value sets used in each environment, and the mechanism that supplies overrides at execution time.
- Supporting definitions: schemas, table definitions, custom stages, and other assets referenced by the selected jobs.
Give unresolved references their own entry. A missing routine should become an assigned discovery task with a due date. Do not silently treat it as an empty function or assume that an identically named development asset matches production.
3. Collect the operational context separately
The design describes transformations; operations supplies evidence of how they run. Capture scheduler definitions, trigger conditions, business calendars, time zones, retry rules, concurrency limits, and upstream arrival checks. Record the actual parameter values or safe references supplied by the scheduler. Include manual runbooks for month-end, backfills, and recovery.
Inventory runtime configuration, mounted directories, file permissions, database drivers, connection
aliases, certificates, and external commands. For traditional installations, IBM documents separate
project environment-variable exports and manual collection of settings files such as
.odbc.init. These instructions illustrate why a design export is insufficient evidence
of the execution environment. See IBM's
DataStage settings migration guidance.
Add recent run evidence: invocation, duration, input size, completion status, and business deadline. Choose an observation period that includes the business cycles being migrated. An unused daily job and a valid annual job can both look inactive during a short review.
4. Keep credentials out of the assessment package
Do not assume exports are free of secrets. IBM warns that encrypted default values can appear in classic XML exports, including passwords stored in stage properties. Its guidance recommends parameters without password defaults, with values supplied at runtime. See IBM's export credential guidance.
The Cloud Pak for Data export documentation
also warns about sensitive connection assets and documents a --no-secrets option.
Check the behavior of your release, then review the
resulting package before sharing it. Record connection purpose, authentication method, credential
owner, and an approved secret reference. Supply target credentials through your organization's
approved process; avoid placing values in a spreadsheet or support attachment.
5. Create a manifest that exposes missing evidence
A manifest connects each asset to its evidence and its owner. Store the export filename, export options, checksum, collection date, dependency status, business use, and proposed disposition. Keep the original package under controlled access and version reviewed copies so that an assessment can be traced back to the exact designs examined.
The following is an illustrative manifest entry, not a customer example:
Asset: Finance/Nightly/LoadInvoices
Type: parallel job
Environment: production
Design evidence: finance-jobs.xml
Dependencies: NormalizeAccount routine; FinanceDB parameter set
Schedule evidence: finance-nightly-schedule.txt
Runtime evidence: finance-runtime-redacted.md
Business owner: finance reporting owner
Technical owner: data integration team
Open item: confirm month-end parameter override
Disposition: migrate; pilot blocked until open item is resolvedStore full checksums and timestamps in the real manifest. Link shared dependencies to their own records so that one updated routine can be traced to every affected job.
6. Check completeness before selecting the pilot
Walk outward from each proposed pilot job. Resolve sequence calls, shared components, dynamic SQL, file paths assembled from parameters, and external scripts. Compare the export inventory with the scheduler and run history: scheduled jobs missing from the export and exported jobs with no identified caller both need investigation.
Agree on a disposition for every scoped asset: migrate, retain temporarily, retire with owner approval, or investigate. Separate complexity from readiness. A short job can still be blocked by unknown inputs, missing credentials, or an unavailable business reviewer. Use complexity scoring to plan engineering effort once those gaps are visible.
A pilot is ready when its dependencies are accounted for, owners are assigned, representative inputs and baseline outputs are available, and its operating requirements are understood. Use the migration testing checklist to define acceptance evidence and the cutover and rollback plan to capture operational handover requirements. The broader DataStage migration guide places this inventory within the full migration process.