Make the next source routine,
on a path you already run.

A canonical data model is one common shape that every source is mapped into, so consumers work from a single model instead of each source’s fields. Systems that describe the same customer, patient or product differently are then reconciled once, at the boundary where data lands, rather than separately in every report, model and agent downstream.

We validate data as it lands, at the integration boundary, before errors reach reports or agents. Incoming records are mapped to the canonical model and checked on every incremental load, not only on the first day. Entity differences are resolved where the integration needs it, so the downstream team handles fewer ingestion errors instead of repairing each one by hand.

Treat the connector, the canonical model and the validation checks as one reusable pattern, and write it down. Each new source then follows the same path instead of becoming its own onboarding project. You keep the connectors, the mappings, the validation design and an onboarding runbook with the written steps to onboard and operate the next source.

The duration is scoped in the first working session, because it depends on the source family and the canonical model in scope, and the price is fixed once the scope is agreed. That session maps the next source you need to onboard to the common model and its checks, so the scope rests on the real source rather than an estimate.

No. A migration moves a whole estate onto a new platform; integration builds a recurring path that each new source joins once the estate is running. If the whole estate is moving, that is the Migrations service in Modernization. Data integration stops at a validated, reusable feed in the common model, ready for analytics, real-time and AI workloads to build on.