The previous article on whether your leadership team can rely on its data focused on finding the source of mistrust in reporting. Now that diagnosis is complete. You know why the report is late, who needs it, and what its numbers should mean. Someone has proposed a new data platform. Before approving it, narrow the question: which part of the work needs to change, and what should work differently afterward?
Start with one complete flow of data. It might run from orders through a sales calculation to a morning dashboard and an export for finance. With a workload defined this way, you can compare how to run it, verify the results, and assign responsibility. A single table is too narrow a starting point if you don't know what writes to it or reads from it. An entire platform can include a lot of work you have no reason to change yet.
Three options, one requirement
Keeping the current solution deserves the same consideration as migrating it. If it serves its purpose, has support, and has someone accountable for its risks, keeping it may be a sound choice. A targeted fix makes sense when you can address a specific cause within the existing flow. Moving the workload becomes an option when an important requirement remains unmet and you can identify a bounded part to test elsewhere.
The following example is entirely hypothetical. Its constraints and timing are chosen to explain the decision. They are not a client experience, migration results, or generally recommended thresholds.
A company needs a sales report for the previous business day by 8:00 a.m. every business day, in its agreed business time zone. The definition of sales is already settled. The problem is that the calculation shares a processing window with other jobs, so it cannot reliably meet the morning deadline under the current conditions. For this example, assume that changing the query or the schedule alone would not remove that constraint.
| Option | What it would mean in this example | Decision and reason |
|---|---|---|
| Keep it | Continue using the current calculation and processing window. | Does not meet the morning availability requirement. |
| Apply a targeted fix | Change the query or its schedule within the current solution. | Under the stated assumptions, this would not remove the shared constraint. Reconsider this option if the constraint can be removed. |
| Move this workload | Calculate the report in a separate reporting environment. | Test as a candidate because it may allow an independent processing schedule. Switching over is not yet approved. |
The decision is to test moving sales reporting. The order system keeps accepting orders and remains the source of record. Other parts of the data platform are outside the scope. Replacing the entire platform would require additional reasons that this example does not provide.
Look beyond the morning dashboard to the quarterly export
The scope of a move depends partly on what the same data produces less often. In this example, finance uses a quarterly export built from the same sales data. It might never appear in a typical week's logs. It still needs to be included in testing and in the decision to retire the old jobs.
Alongside the logs, review export schedules and confirm usage with the people responsible. Google Cloud's migration assessment documentation specifically calls out tables used only once every three or six months. A quiet stretch in the logs does not prove that nobody needs the data anymore.
The workload therefore includes the sales calculation, morning dashboard, and quarterly export. Moving it also requires access permissions, job scheduling, and responsibility for handling failed refreshes. Moving the files and tables alone would not deliver working reporting.
What the new solution has to prove
Matching row counts are a useful check, but they don't tell you whether the report still means the same thing. Two tables can have the same number of rows while handling cancellations or assigning orders to days differently.
In this example, both reporting paths receive the same finalized snapshot of source data. The team compares keys and duplicates, then sales by day and sales channel, using the same precision for monetary amounts and the same business-day cutoff. It checks refunds, canceled orders, and late corrections separately. The finance lead confirms which order statuses are included, what the results mean, and whether the quarterly export keeps its format. This establishes whether finance can use the report to make the same decisions after the move.
Everyday operation also has to pass before the switch: an authorized user can open the report, an unauthorized role cannot, and a failed refresh is visible. The report must not present yesterday's successful refresh as fresh data for today.
For illustration, the team requires five consecutive daily refreshes to finish by 8:00 a.m., plus a successful test using representative quarter-end data. Five runs are a specific condition for this decision, not a universal demonstration of reliability. And a quarter-end test is not an actual quarterly close.
Costs belong in the same decision. Compare all three options for the same workload, data volume, and period. Record recurring operating costs separately from one-time work. If the original platform will keep serving other jobs, moving one report may not reduce its bill. You cannot count that entire bill as savings.
Alongside future operating costs, account for the temporary period when both paths run, duplicate ingestion and storage, data transfer, validation, support, and eventual removal of unneeded components. In this example, the sponsor requires recurring costs after the agreed retirement of old components to be no higher than the documented current operating cost of this reporting workload. The budget for running both paths temporarily needs separate approval. Until the amounts and conditions are known, the switch stays on hold. Changing environments does not, by itself, demonstrate savings.
Rolling back has to account for new data
The CTO approves the cutover—the switch to the new reporting path—based on the data team's evidence and the finance lead's acceptance of the results. Both paths must have processed the same completed source snapshot. The team records its identifier and the connection versions, then redirects only the report's readers. Order writes do not change. If any condition is unmet, the cutover does not happen.
In this example, the old reporting path keeps refreshing from the same authoritative source data for ten business days in case something goes wrong. A serious error in calculations, permissions, or data freshness causes the team to pause publication of results. The CTO approves a rollback based on the data team's verification. Readers return to the old path only after the team confirms that it has processed the latest accepted source snapshot, including new orders and corrections through that snapshot's cutoff.
This rollback depends on an important boundary: the new environment is used only for derived reporting. It receives no independent business writes or manual corrections that exist nowhere else. If those changes were introduced, simply switching the connection back could lose them. The team would first need to transfer and reconcile them. AWS similarly distinguishes rollback without data changes from rollback after new writes, when the original copy may already be stale.
The team rehearses the rollback before cutover. If it cannot verify the old path, publication stays paused; an unverified report is not a fallback. Ten business days is the observation period chosen for this example. It does not automatically include a quarterly close or authorize retiring the old reporting path when the period ends.
Retiring the old components has its own conditions
After ten business days, the team reviews operations. The old daily reporting job and view can be removed only after the results have been accepted, rollback has been verified, remaining dependencies have been checked, and the definitions and materials needed for recovery have been preserved. A table stays if another job still reads it.
The old quarterly export path stays in service longer: until the finance lead accepts an actual quarterly run on the new path. The earlier test provided evidence for switching the daily report, but it does not justify removing this dependency. A decision to move sales reporting may therefore lead to several different retirement dates. It sets no retirement date for the entire data warehouse.
Write down a decision you can revisit
The record should preserve why an option was chosen and the conditions under which that choice still holds. Architecture decision records, or ADRs, also use an owner, context, and consequences to document a decision. A concise record for this example might read:
SALES-01 — approved for a limited validation; cutover remains pending. We will test separate sales reporting because, under the stated assumptions, neither keeping the current solution nor the proposed fix meets the morning deadline. We will not move the order system or other jobs. The CTO owns the technical decision; the finance lead accepts the meaning of the results and the quarterly export. Cutover requires the data, operational, and cost conditions to be met, with a rehearsed rollback to an up-to-date original path. The review takes place ten business days after the actual cutover. We will retire the old quarterly export path only after an actual quarterly run in the new environment has been accepted. We will reopen the decision if approved costs are exceeded, the morning deadline is missed, independent writes are introduced in the new environment, or a dependency prevents the planned retirement.
This is a completed decision about the next step. It does not claim that validation or migration has succeeded. The completed example and blank worksheet provide room to record responsibilities, evidence, and conditions in full.
If you already understand the cause of the problem and need to compare options and the scope of change, we can work through them as part of data and AI systems architecture. If you still don't know why the numbers or reports are unreliable, a data audit is a suitable first step.