Carry forward the business rules
Begin with the source stage graph and column derivations. Identify joins, lookups, filters and calculations that define the result. Capture expected behaviour for unmatched records, duplicate keys and rejected rows before rewriting it.
Choose an execution shape
Spark notebooks and lakehouse tables provide a starting point for the target design. Microsoft Fabric supports Spark notebooks, and its Data Factory notebook activity can run those notebooks inside a pipeline.
PipelineX generates target code for engineering review. Inspect the stage mappings, function translations and conversion findings for each job, then configure its connections and runtime for the intended environment.
Make it operational
Decide which lakehouse owns the data, how notebooks are parameterized and how pipeline activities start and monitor execution.
Keep environment-specific settings separate from transformation logic. Check permissions, failure handling, rerun behaviour and monitoring with the team that will operate the workload.
Compare the result
Run source and target against controlled inputs. Compare schemas, business keys, record counts, nulls, duplicate behaviour and important aggregates. Investigate record-level differences before accepting the migration.
Test edge cases deliberately: an unmatched lookup, an empty feed, a duplicate join key and a value near a decimal or date boundary.
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.
Connect the prepared package to your repository
Use configured GitHub or Azure DevOps connections to save a prepared Fabric package to a review branch, open a draft pull request and refresh checks for its recorded commit. The customer’s repository policies govern review and merge.
Read the Fabric release and CI/CD workflow for package checks, runtime evidence and deployment setup.