/ use cases · migration
Know what will breakbefore you migrate it.
Migration programmes overrun because discovery happens during delivery. The gaps that matter surface late, and each one costs a change request.
/ the problem
Discovery happens during delivery, which is the wrong end of the programme.
The gaps that matter — the field with no equivalent, the value the target will not accept, the system nobody mentioned — surface late, and each one costs a change request.
/ the journey
Discover → Map → Compare → Identify gaps → Model impact → Plan → Migrate → Verify.
Discover
What exists, read from the systems.
Map
Source and target to the canonical layer.
Compare
The two understandings, against each other.
Identify gaps
What has no equivalent, and what is ambiguous.
Model impact
What else depends on what is moving.
Plan
Sequence derived from the dependencies.
Migrate
With the rules already derived.
Verify
That the result means what the source meant.
/ a mapping, in detail
An example, not a customer run.
Public field names, classified by Inferrex. Not output from a customer estate.
| Source field | Target field | Status | Detail |
|---|---|---|---|
| `Contact.Email` | `contact.email` | Matched | Same canonical key, same type. |
| `Contact.CreatedDate` | `contact.created_at` | Transformed | ISO 8601 with offset to Unix epoch seconds. |
| `Contact.Owner.Id` | *none* | Missing | No ownership concept in target. Requires a decision, not a mapping. |
| `Contact.LeadSource` | `contact.source` | Ambiguous | Source enumerations overlap but do not align. Three values need a rule. |
| `Contact.Territory__c` | *none* | Unsupported | Custom object with no target equivalent under the current scope. |
Matched fields migrate. Transformed fields migrate with a derived rule. Missing, ambiguous and unsupported fields are the programme's actual scope, and they are known before it starts.
Inferrex doesn't replace the migration programme. It removes the uncertainty before the migration programme starts.
A migration sequence is only as good as the dependencies. Application dependency mapping is that picture. The field-level work is schema mapping.
Establish the dependency map before the sequence is agreed.
Discovery done properly is the cheapest phase of a migration and the one most often skipped.