Migration order
- Most consequential system: Legacy ERP module (stops 4 items).
- For this scenario: none stops none.
AutoDiscover
Each tool keeps its own idea of who, what and which system, so they disagree.
Demonstration: Marlowe Textiles Ltd (fictional) · Manufacturing and export. Fictional data and a scripted answer.
If a source system is retired, which parts of our business model lose their data?
Fail one or more items and see what stops and what only degrades, worked out by following the dependencies.
Choose what is retired. Hard dependencies stop with it; soft ones carry on, degraded.
Simulated answer. Written for this fictional case, not produced by a live model. Only the figures in it are computed, from what you decided above.
Following the mappings, none stops none and degrades none [S1][S2]. The most consequential system in this map is Legacy ERP module, whose retirement stops 4 other item(s).
A knowledge model of the organisation is what lets such a question be answered before the retirement, not after. The only-source entities (here, products) need a new home first.
Relies on: S1 · Discovered systemsS2 · Entity to source mapping
The enterprise architect decides. Approving fixes the migration order for the retirement plan. It does not move any data or switch off any system.
Not ready to approve. Fail at least one item first, to see what depends on it.
In the product this is a different person with the right permission. Here you play that role to see the rule.
The AutoDiscover story · This capability in the full register