{ "site": "DATANALYSIS", "id": "DATA-MODERNISATION-N1-20261110", "locale": "en", "status": "release_ready", "version": "1.0.0", "robots": "index, follow", "preparedAt": "2026-11-10", "updatedAt": "2026-11-10", "publishedAt": "2026-11-10", "title": "Modernising a data platform while the business keeps working", "description": "Prepare a data platform cutover: uses to preserve, a coherent scope, comparison against an explicit reference, the go-ahead decision and rollback with new writes, with a migration map.", "lede": "A new platform can be technically ready while the applications and teams that depend on its data are not ready to change. The delivery date of the new environment and the cutover date of the uses are two different decisions.", "intro": [ "To prepare the second one, you need to look at what produces the data, what transforms it and what uses it. The method below proposes five decisions to document on a first scope. It prescribes neither a complete migration nor a particular tool." ], "sections": [ { "id": "uses-to-preserve", "heading": "1. Start from the uses that must continue", "blocks": [ { "p": "A dataset can feed an application, an invoicing process, a partner export and reporting. These consumers do not necessarily have the same constraints on timing, format or availability." }, { "p": "The map must therefore connect applications, flows, rules and owners. It must also flag uses that are still unknown. An export reworked by hand or a poorly documented legacy process may not appear in the first technical views." }, { "p": "AWS guidance on preparing a cutover stresses dependencies, tests, responsibilities and the transition runbook. [1] For our scoping, the expected result is a usable list: which use must be preserved, who signs it off and what evidence will show that it works after the change?" } ] }, { "id": "coherent-scope", "heading": "2. Choose a coherent scope", "blocks": [ { "p": "The first step is not necessarily the smallest table or the least visible application. It must form a set that the team can migrate and verify without leaving essential dependencies aside." }, { "p": "A progressive approach can limit the scope of each cutover, but it adds a period of coexistence. You then have to maintain the interfaces, understand which system is authoritative and manage any differences between the two paths. A grouped cutover may be necessary when components are tightly coupled. The choice depends on the architecture and the constraints of the business. [2]" }, { "p": "The useful decision is therefore not “migrate everything or do nothing”, but “which uses can move together, with which checks and which stop conditions?”" } ] }, { "id": "compare-reference", "heading": "3. Compare on the basis of identified rules and data", "blocks": [ { "p": "Comparing two totals is not enough if the periods, rules or starting data differ. Before acceptance testing, the team must set the time reference, filters, units and special cases that define the expected result." }, { "p": "A gap can come from the new process, from an update to the source or from a business rule that was changed during the project. Without an explicit reference, the team risks treating all these changes as a single anomaly." }, { "p": "Checks must cover the results, but also availability times, access rights and the behaviour of consuming applications. Data that is correct in the platform can still be read in the wrong unit or arrive too late for a use." } ] }, { "id": "cutover-decision", "heading": "4. Assign the cutover decision", "blocks": [ { "p": "The go-ahead should not boil down to “the jobs are green”. You need to know which technical and business sign-offs are expected, which have been obtained and which reservations remain open." }, { "table": { "caption": "Cutover decisions and what to document", "head": [ "Decision", "What to document" ], "rows": [ [ "Scope", "Applications, flows, uses and exclusions." ], [ "Reference", "Datasets, periods and rules used for the comparison." ], [ "Validation", "Expected result and owner of each check." ], [ "Go-ahead", "Person authorised to decide, criteria and acceptable reservations." ], [ "Monitoring", "Immediate post-cutover checks, observation period and alert recipients." ], [ "Stop or rollback", "Triggers, owner and handling of data already produced." ] ] } }, { "p": "The runbook must specify the order of operations and the points where the change can be interrupted. A rehearsal in a suitable environment lets you test the plan against real dependencies; it does not turn the remaining assumptions into guarantees." } ] }, { "id": "rollback-new-writes", "heading": "5. Prepare rollback together with the new writes", "blocks": [ { "p": "Going back to the old code is not always enough. Operations may have been recorded after the cutover. You have to decide how they will be kept, reconciled or replayed, without loss or duplicates." }, { "p": "The strategy must also cover outputs already distributed to applications and partners. A correction in the platform does not automatically withdraw a file that was sent or a decision taken on the basis of an incorrect result." }, { "p": "Cutover guides stress this need to plan rollback and the handling of modified data. [1][2] The project must identify the point beyond which a simple rollback is no longer appropriate and a recovery or correction procedure becomes necessary." } ] }, { "id": "map-first-step", "heading": "Turn the map into a first work step", "blocks": [ { "p": "The accompanying migration map is used to prepare a meeting between application owners, the data team, operations and the business. It brings together the scope, the expected evidence, the sign-offs and the rollback conditions." }, { "p": "It may reveal that a problem presented as a migration is first of all about a definition, a flow or a poorly controlled dependency. Dealing with that point can become the first step of the project, without presuming the complete trajectory." } ] } ], "body_markdown": "## 1. Start from the uses that must continue\n\nA dataset can feed an application, an invoicing process, a partner export and reporting. These consumers do not necessarily have the same constraints on timing, format or availability.\n\nThe map must therefore connect applications, flows, rules and owners. It must also flag uses that are still unknown. An export reworked by hand or a poorly documented legacy process may not appear in the first technical views.\n\nAWS guidance on preparing a cutover stresses dependencies, tests, responsibilities and the transition runbook. [1] For our scoping, the expected result is a usable list: which use must be preserved, who signs it off and what evidence will show that it works after the change?\n\n## 2. Choose a coherent scope\n\nThe first step is not necessarily the smallest table or the least visible application. It must form a set that the team can migrate and verify without leaving essential dependencies aside.\n\nA progressive approach can limit the scope of each cutover, but it adds a period of coexistence. You then have to maintain the interfaces, understand which system is authoritative and manage any differences between the two paths. A grouped cutover may be necessary when components are tightly coupled. The choice depends on the architecture and the constraints of the business. [2]\n\nThe useful decision is therefore not “migrate everything or do nothing”, but “which uses can move together, with which checks and which stop conditions?”\n\n## 3. Compare on the basis of identified rules and data\n\nComparing two totals is not enough if the periods, rules or starting data differ. Before acceptance testing, the team must set the time reference, filters, units and special cases that define the expected result.\n\nA gap can come from the new process, from an update to the source or from a business rule that was changed during the project. Without an explicit reference, the team risks treating all these changes as a single anomaly.\n\nChecks must cover the results, but also availability times, access rights and the behaviour of consuming applications. Data that is correct in the platform can still be read in the wrong unit or arrive too late for a use.\n\n## 4. Assign the cutover decision\n\nThe go-ahead should not boil down to “the jobs are green”. You need to know which technical and business sign-offs are expected, which have been obtained and which reservations remain open.\n\n| Decision | What to document |\n|---|---|\n| Scope | Applications, flows, uses and exclusions. |\n| Reference | Datasets, periods and rules used for the comparison. |\n| Validation | Expected result and owner of each check. |\n| Go-ahead | Person authorised to decide, criteria and acceptable reservations. |\n| Monitoring | Immediate post-cutover checks, observation period and alert recipients. |\n| Stop or rollback | Triggers, owner and handling of data already produced. |\n\nThe runbook must specify the order of operations and the points where the change can be interrupted. A rehearsal in a suitable environment lets you test the plan against real dependencies; it does not turn the remaining assumptions into guarantees.\n\n## 5. Prepare rollback together with the new writes\n\nGoing back to the old code is not always enough. Operations may have been recorded after the cutover. You have to decide how they will be kept, reconciled or replayed, without loss or duplicates.\n\nThe strategy must also cover outputs already distributed to applications and partners. A correction in the platform does not automatically withdraw a file that was sent or a decision taken on the basis of an incorrect result.\n\nCutover guides stress this need to plan rollback and the handling of modified data. [1][2] The project must identify the point beyond which a simple rollback is no longer appropriate and a recovery or correction procedure becomes necessary.\n\n## Turn the map into a first work step\n\nThe accompanying migration map is used to prepare a meeting between application owners, the data team, operations and the business. It brings together the scope, the expected evidence, the sign-offs and the rollback conditions.\n\nIt may reveal that a problem presented as a migration is first of all about a definition, a flow or a poorly controlled dependency. Dealing with that point can become the first step of the project, without presuming the complete trajectory.", "closing": "Let’s review a modernisation scope with DATANALYSIS. Bring the applications concerned, the uses to preserve and the change you are considering. We can scope the dependencies, the sign-offs and a coherent first step.", "cta": { "label": "Review my modernisation scope", "url": "https://datanalysis.re/contact?lang=en" }, "worksheet": { "label": "Open the migration map (printable HTML)", "url": "https://datanalysis.re/ressources/data-engineering/modernising-data-platform-while-business-runs/migration-map", "fields": [ [ "Scope and uses", "A dataset feeding an application, an invoicing process, a partner export and reporting; uses to preserve, exclusions and still-unknown uses flagged." ], [ "Dependencies and owners", "Applications, flows, rules and owners connected; hand-reworked export and poorly documented legacy process to check; one named approver per use." ], [ "Reference and tests", "Time reference, filters, units and special cases set before acceptance testing; checks on results, availability times, access rights and the behaviour of consuming applications." ], [ "Sequence and go-ahead", "Order of operations and interruption points; person authorised to decide, criteria, sign-offs obtained and acceptable reservations; rehearsal in a suitable environment." ], [ "Stop, rollback and new writes", "Triggers and owner; operations recorded after the cutover kept, reconciled or replayed without loss or duplicates; outputs already distributed; point beyond which a recovery or correction procedure becomes necessary." ], [ "Monitoring, evidence and date", "Immediate post-cutover checks, observation period and alert recipients; expected evidence per check; review date (fictional example: no real date)." ] ], "pdf": "https://datanalysis.re/downloads/data-modernisation-carte.en.pdf" }, "pdf": { "article": "https://datanalysis.re/downloads/data-modernisation-article.en.pdf", "worksheet": "https://datanalysis.re/downloads/data-modernisation-carte.en.pdf", "pack": "https://datanalysis.re/downloads/data-modernisation-pack-fr-en-de.zip" }, "related_articles": [ { "title": "When data changes meaning: preparing changes across applications", "url": "https://datanalysis.re/ressources/data-engineering/data-changes-meaning-across-applications" }, { "title": "Resuming a data flow without multiplying its effects", "url": "https://datanalysis.re/ressources/data-engineering/resuming-data-flow-without-duplicate-effects" } ], "sources": [ { "n": 1, "label": "AWS Prescriptive Guidance | Migration cutover best practices: pre-cutover stage", "url": "https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-migration-cutover/pre-cutover-stage.html", "note": "cutover preparation: dependencies, tests, responsibilities, transition runbook and rollback" }, { "n": 2, "label": "AWS Prescriptive Guidance | Migration cutover best practices: cutover stage", "url": "https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-migration-cutover/cutover-stage.html", "note": "cutover execution, rollback and handling of modified data" } ], "sources_note": "References consulted on 10 November 2026. The map and wording are a teaching adaptation of preparation and control principles. They do not constitute an executable migration plan without a review of your environment.", "canonical": "https://datanalysis.re/ressources/data-engineering/modernising-data-platform-while-business-runs", "alternates": { "fr": "https://datanalysis.re/ressources/data-engineering/moderniser-plateforme-data-continuite-activite", "en": "https://datanalysis.re/ressources/data-engineering/modernising-data-platform-while-business-runs", "de": "https://datanalysis.re/ressources/data-engineering/datenplattform-modernisieren-laufender-betrieb" } }