André’s Reviews > Practical Data Migration > Status Update

data mig project gone wrong→stabilize +planned activity:
・don't do more of whatever you were doing before
・prolly compromised Golden Rules 1 & 2: Mig is a business not tech responsibility & biz knows best→given the disaster, biz & data stakeholders won't take respo. now→respo. for solution not problem
・succumbed to groupthink that the major Legacy Data Store only source of data
・prioritize
・weekly release strategy
・…

System Mig Design Spec:
・timetable with check points
・technical: load + (fallback) unload program spec, transient stores, leg. data stores changes, non-functional capabilities of the mig plattform (servers, DB, network)
・amendments to stage 1 and 2 sys. retirement policies
・fallback plan
Test Migration:
・use ETL defs & retirem. policies (priorities, metrics)
Build Mig Software
Execute Mig
Post-Impl Review
・mopping up

・resist moving forward in Stage 2 DataPrep unless assured that the tentative design you are working to is unlikely to alter
・gap analysis key techniques:
access path analysis to id access gaps,
data structure analysis (synonyms/homonyms, …),
data gap analysis to id missing items
・fill gaps: see if problem has been solved already in some obscure database
・Data Quality Rules for Extract, Transform, Load definitions

・use company's BizReadiness [change mgt] team if exist [comm. upcoming changes]
・MigStrategy proj. initiation doc for sponsor+programme mgt
・reporting strategy
・time boxing
・keep DQRules autonom ⇒ proj plan simpler (reduce cross-deps)
・compromises alw by DataStakeh.:
prioritize; the 20% effort to get 80% cleansed; go live w/ data probs+clean over time or accept
・fixed timeline⇒only qualy, resources or qnty can change

Data mig analyst skills:
・data analysis
・data model composition & comparison (gaps, overlaps, …)
・on-the-fly tmp. business process dev. to fulfill Data Quality Rules & Data Transit. Rules reqm.
・understanding of query level access to local technology
・good at interviewing & running workshops
・persuade programme manager of running Mig as separate project
・no early data preparation→f*ups when low budget and short time

・Data Gaps: display a single target-system conceptual entity with its linked entities in our original KBDA model→correct model, uncover missing entities
・infer missing data from other data→search LegacyDataStore catalogue for stores related to KBDA
・Data Mapping 1:1, 1:M, M:M→validate, transform, (manual/best guess) cross-reference tables, defaulting, ratios: 70% 1:1, 25% M:1, 5% manual recovery exercise after event

Data Quality Rules (Meeting):
= actions to ensure legacy data will be fit for loading
・early quality⇒cheaper
・Suitable data qualy?
・address store(s) or KeyBizDataArea
・round 1: make stores internal consistent, c. with KBDA model, correspond w real world
・unoff. derived data stores within user community (Sys→Excel) at better quality?
・round 2: make cleaned data mapable to new sys: amend data structs, gen. missing data

・id LegacyDataStores→decompose datamig project into max 12 signif. logical entities ("KeyBizDataAreas")
・top-down, iter., pragm.
・prefer datacentric model over biz fn, org bound., target modules→find scat. missing links, manual re-keying
・model exist & future KBDA to uncover data gaps
・RetiremPolicy
・accuracy→audit trail,user tests
・TransitRules: temp. upd old+new store, data freeze
・lots of small sign-offs > big one

Rules:
・Datamig is a biz not tech issue: Avoid implicit promise enterprise going to have passive role, enterp. must own delivery + solutions to ur probs
・Biz knows best
・No org needs/will pay for perfect qual. data
・measure

Stakehol:
・Data Store Owners: Silos, Excel anarchy, Who authz. decommission?
・Biz Domain Experts
・Technical Data Ex.
・Programme Ex.
・Corp Data Architect
・Audit/Regul. Ex.
・Data Cust: External use

- published 2005
- "aimed at the gap in the methodologies that will allow you to develop the perfect system then say nothing about how you get the best legacy data out of the flaky old systems you are trying to leave behind"
- [heute gibt es und mW. gab es auch seinerzeit Migrationsbücher, zB. M. Brodies "Migrating Legacy Systems: Gateways, Interfaces & ..." (1995), Strangler-Pattern usw.; trotzd. eher stiefmütterl.]