Understand the estate. Make the next move.

Take your DataStage migration from scope and planning through code review, validation and release preparation. PipelineX brings job designs, dependencies, generated code and migration evidence into the work.

One workspace, from scope to handover.

The project connects the people, source jobs and delivery plan. Explore how the work stays connected through migration and release.

Your starting point

Projects & teams

Connect the outcome, Catalog, owners and migration waves in one project.

Scope & assign
  • Source & intended scope
  • People & destination
  • Waves & milestones
Explore projects & teams
  1. 1Catalog

    Import diagnostics

    See what the XML captured, what needs investigation and which findings affect each destination.

    Jobs, sequences & dependencies
  2. 2Migrations

    Generate & review

    Group related jobs, choose a destination and keep code revisions, owners and review decisions connected to the source.

    Validate & accept
  3. 3Releases

    Releases & CI/CD

    Take prepared Fabric packages into repository review, checks and runtime validation.

    Release & hand over

Migration reports

Follow assigned work, blockers, current acceptance evidence and operational handover.

Explain job logic, discuss migration risks and review saved code. Explore the AI Migration Assistant.

AI Migration Assistant

Bring the job’s logic into the conversation.

Explain transformations, review saved code and plan validation with your selected DataStage job as context.

  • SQL & derivations
  • Schemas & sequences
  • Saved migration evidence
Explore the AI Migration Assistant See what it can read
PipelineX demo: the AI Migration Assistant focuses on a selected DataStage job, with questions about its flow, transformation rules and migration risks. The Catalog sits behind it.
Your selected job. Its context. A place to ask.

See what you actually have

Import a DataStage XML export and explore the jobs it describes. Read stage layouts, follow links, inspect column derivations and see how jobs relate. Use the original design as the starting point for a migration discussion.

An export describes the job design. Runtime schedules, credentials, external scripts and production data still need their own inventory.

Work from logic to code

Choose a job and a destination: Microsoft Fabric, Databricks or Snowflake. Generate a preview, inspect the transformation logic and work through the parts that need engineering attention.

Keep the source alongside the output while reviewing joins, filters, lookups and calculations. Translation gives your team an artifact to inspect and develop; deployment requires configuration and testing in your environment.

Plan around the work that remains

Use the job inventory, dependency views and complexity indicators to choose a representative pilot. Organize migration waves, record review decisions and keep unresolved questions visible.

Connect each review decision to its source version, generated artifacts and supporting evidence so the next engineer can follow the work.

Grant access to approved accounts

Configured customer deployments support Microsoft Entra sign-in for accounts explicitly provisioned and linked by a PipelineX administrator. Microsoft sign-in never creates an account. Administrator, engineer, reviewer and viewer permissions are enforced by the application, and dedicated customer deployments can use customer-specific data directories.

You approve the PipelineX account and its role, then link the verified Microsoft identity. An unlinked identity receives no access, even when its email matches an existing account.

Prepare a reviewed Fabric deployment

Export notebook and pipeline definitions with a deployment script that integrates Microsoft's fabric-cicd, environment settings and an Azure DevOps pipeline template. Review conversion findings alongside the source. A deployment review is tied to the exact package and destination settings, so changed inputs require renewed review.

Configure Fabric access, review connection bindings and prepare environment-specific releases. See Microsoft's fabric-cicd documentation.

Check migration order and change impact

Check recorded prerequisites before scheduling migration waves. See missing or ambiguous dependencies, cycles and upstream jobs planned to finish too late. Trace downstream jobs for renewed review when an upstream source or recorded artifact reference changes.

The suggested order describes recorded dependencies and sequence child availability. Your team confirms external dependencies and runtime scheduling.

Report remediation and recorded progress

Group conversion blockers by finding and affected job, and export the report. Record remediation, review, testing and deployment hours alongside accepted jobs. Throughput uses entered effort and current review evidence, with missing time coverage shown explicitly.

No recorded hours means no throughput rate. Stale acceptance is excluded, and repeat acceptance does not inflate the job count.

Begin with a representative job

Choose a job that contains real business logic and a manageable set of dependencies. Bring its export, a description of the expected result and your intended target. That creates a more useful starting point than an estate-wide conversion percentage.

Connect the project, people and delivery

Define the project outcome, source identity, destination and delivery lead. Group related jobs into migrations, assign responsibilities and plan waves. My work brings assigned actions back to each person, while shared jobs keep one delivery record per destination.

Explore projects and teams, then follow current evidence through migration reporting.

Inspect what the import actually captured

Follow resumable uploads and parsing activity, then review jobs encountered, imported and not imported. Search import errors, source-capture findings and conversion blockers by job, stage and target platform. Download the diagnostic report to support remediation.

See how DataStage XML import diagnostics connect the Catalog to the engineering work.

Take Fabric packages into repository review

Save a prepared Fabric package to a new branch in a configured GitHub or Azure DevOps repository, open a draft review and follow checks for the recorded commit. Keep package checks, runtime validation and migration acceptance connected to the release.

Explore releases and CI/CD, including customer setup and the scope of each check.

Continue from here

Plan a DataStage migrationExplore supported destinationsDiscuss your estate