If you haven’t already, check out Arun Ulag’s hero blog “FabCon and SQLCon 2026: Unifying databases and Fabric on a single, complete platform” for a complete look at all of our FabCon and SQLCon announcements across both Fabric and our database offerings.
Introduction
Copy job is the go-to solution in Microsoft Fabric Data Factory for simplified data movement across multiple clouds. With native support for bulk copy, incremental copy, and change data capture (CDC) replication, it can handle a wide range of movement scenarios through an intuitive, easy-to-use experience.Change data capture (CDC) is the backbone of modern data replication. When your operational systems change — new orders, updated customer addresses, canceled subscriptions — your analytics environment needs to reflect those changes quickly and accurately. But building and maintaining CDC replication jobs has traditionally required deep engineering effort with custom code and complex logic to handle deletes and history.
We’re introducing a set of enhancements to Copy job in Microsoft Fabric Data Factory that make CDC replication significantly richer and easier — all without writing a single line of code:
- Oracle CDC source — Capture changes directly from Oracle databases.
- Fabric Data Warehouse sink — Replicate CDC data into Fabric Data Warehouse.
- SCD Type 2 — Preserve full history with effective dating, and handle deletes as soft deletes.
What's new
Oracle CDC source
Oracle databases remain a cornerstone of enterprise transactional systems — from ERP and financial platforms to supply chain and HR applications. Copy job now supports Oracle as a CDC source, enabling you to capture inserts, updates, and deletes from Oracle tables and continuously replicate them to any supported destinations.Fabric Data Warehouse sink
Now, you can also replicate CDC data directly into Fabric Data Warehouse — giving you the option to land your continuously updated data into a fully managed, SQL-based analytical engine with T-SQL query support, stored procedures, and enterprise-grade security.SCD Type 2: Full history tracking with soft delete
This is the one that changes the game. Copy job now supports SCD Type 2 — the industry-standard pattern for preserving complete change history — paired with built-in soft delete handling, so when a record is deleted at the source, the destination row is marked as inactive rather than physically removed. SCD Type 2 gives you a complete, audit-ready view of how your data evolved over time, including records that no longer exist in the source.Supported connectors:
- Azure SQL DB
- Azure SQL Managed Instance
- SQL Server
- Fabric SQL Database
- Fabric Lakehouse table
Slowly Changing Dimension Type 2 (SCD Type 2) is one of the most well-established patterns in data warehousing. The core idea is simple: when a dimension record changes, don't overwrite it — insert a new version and preserve the old one.
Consider a customer table. A customer moves from California to New York. With a simple overwrite (SCD Type 1), you lose the fact that they were ever in California. Every historical transaction linked to that customer now shows "New York," even for orders placed years ago when the customer was in California.
With SCD Type 2, both versions are preserved:
| CustomerKey | CustomerID | Name | State | Valid_From | Valid_To | Is_Current |
|---|---|---|---|---|---|---|
| 1001 | C-123 | Acme Corp | CA | 2023-01-15 | 2026-02-20 | No |
| 1002 | C-123 | Acme Corp | NY | 2026-02-20 | 9999-12-31 | Yes |
Now your analytics can answer both "Where is this customer today?" and "Where was this customer when they placed that order in 2024?" — a critical distinction for accurate reporting, regulatory compliance, and business intelligence.
But history tracking doesn't end with updates. What happens when a record is deleted from the source? In a traditional overwrite model, the row simply disappears from the destination. In an SCD Type 2 model, the record isn't removed. Instead, its current version is closed: ValidTo is set to the deletion timestamp and IsCurrent is flipped to false. The record remains in the table, fully queryable, preserving the complete lifecycle of that entity from creation through every change to its eventual removal. This is critical for compliance ("prove this customer existed and what state they were in"), for audit trails, and for analytics that require complete population snapshots at any point in time.
Why it matters across industries
SCD Type 2 isn't an abstract data modeling exercise. It directly impacts business-critical scenarios:- Financial services — Regulatory reporting requires knowing the exact state of a customer account or risk classification. Overwriting history creates compliance gaps.
- Healthcare — Patient records, provider affiliations, and insurance plan assignments change over time. Treatment analysis must reflect the state of the patient's profile at the time of care, not today.
- Retail and e-commerce — Customer segments, product pricing tiers, and loyalty statuses change. Promotional effectiveness analysis requires knowing what segment a customer was in when they made a purchase.
- Manufacturing and supply chain — Supplier certifications, material specifications, and routing assignments evolve. Quality audits require point-in-time traceability.
- Insurance — Policy terms, coverage limits, and agent assignments change with each renewal. Claims analysis must tie back to the policy version that was active at the time of the claim.
Why it's traditionally hard to implement
Despite being a well-known and widely needed pattern, SCD Type 2 has been notoriously difficult to implement in practice. Here's what a typical code-based implementation involves:- Detect which source rows changed — Compare the incoming CDC stream against the current version of each row in the destination.
- Close the current version — For changed rows, update the existing "current" record: set the ValidTo date to now, flip IsCurrent to false.
- Insert the new version — Insert a new row with the updated values, ValidFrom set to now, ValidTo set to a high-date sentinel (e.g., 9999-12-31), and IsCurrent set to true.
- Handle deletes with soft delete — When a CDC delete event arrives, don't physically remove the destination row. Instead, close the current version by setting ValidTo and IsCurrent = false, preserving the record for audit and historical analysis.
Copy job makes it one step
In Copy job, enabling SCD Type 2 is not a coding exercise. It's a configuration choice with one step.How it works
In Copy job, enabling SCD Type 2 is a configuration choice with one step:- Create a Copy job
- Select a CDC-supported source
- Select a supported destination
- Turn on SCD Type 2 (write method)
Figure: Screenshot of enabling SCD2 in Copy job.
CDC with SCD Type 2 in Copy job Is another proof point for code-free data movement
Copy job was built to simply your data movement with native data movement patterns without any code required. Bulk copy, incremental refresh, and scheduling were the first proof points — tasks that every data team needs, delivered through a no-code experience that anyone can use.CDC replication with SCD Type 2 is the next, and arguably the most compelling, proof point. This is a pattern that has existed in data warehousing for decades, that every enterprise eventually needs, and that has stubbornly resisted simplification. With Copy Job, SCD Type 2 is enabled through a single toggle, is a statement about what no-code tools should be capable of.
The value becomes starkly clear when you compare Copy job side-by-side with what the same task requires on code-centric platforms.
Implementing SCD Type 2
| Aspect | Code-Based Platform | Copy job (No-Code) |
|---|---|---|
| Setup time | Days to weeks (connectivity, libraries, custom code, testing) | Minutes (select source, destination, toggle SCD2) |
| MERGE logic | Write and maintain MERGE INTO with WHEN MATCHED / WHEN NOT MATCHED clauses per table | Generated automatically by the platform |
| SCD Type 2 + soft delete | Manually add ValidFrom, ValidTo, IsCurrent; write separate code paths for updates vs. deletes; manage version transitions and soft-delete close-out | One step — both history tracking and soft delete are enabled together, applied consistently across all selected tables |
| Per-table effort | Each table needs its own MERGE logic (or a parameterized framework you build yourself) | Select tables in bulk — SCD2 applies uniformly |
| Scaling to 100+ tables | Build and maintain a custom framework; significant engineering investment | Same experience whether it's 1 table or 500 |
| Maintenance | Ongoing: handle edge cases, Spark or other framework version upgrades, library compatibility | Zero code to maintain — platform handles updates |
| Skill requirement | Spark/PySpark/SQL expertise, CDC domain knowledge | Business user with basic data understanding |
Coming from Azure Data Factory? Unlock more value with Copy job in Microsoft Fabric beyond ADF CDC
If you're currently using Azure Data Factory for ADF CDC or slowly changing dimension workloads, it's worth understanding how the experience differs.ADF does not offer built-in SCD Type 2 support. As described in the ADF documentation on slowly changing dimensions, implementing SCD Type 2 in ADF requires building mapping data flows with a specific chain of transformations — conditional split to classify incoming rows as inserts vs. updates, derived column to generate surrogate keys and effective dates, alter row to mark rows for insert or update, and a sink transformation configured for upsert behavior. Each table requires its own data flow with this multi-step configuration, and changes to source schema or business rules mean revisiting and updating each flow individually.
There is no one-step SCD Type 2 option in ADF. Copy job in Fabric Data Factory changes this entirely. The same SCD Type 2 pattern that requires per-table data flow authoring in ADF is available as a single toggle in Copy job — applied consistently across all selected tables, with soft delete included, and with zero ongoing maintenance.
If you're evaluating a move from ADF to Fabric, CDC with SCD Type 2 is one of the strongest reasons to make that transition. The ADF to Fabric migration guide provides step-by-step instructions to help you get started.
Learn more
Submit feedback on Fabric Ideas and join the conversation in the Fabric Community.Questions or feedback? Leave your thoughts in the comment section.