Planning a Billing System Migration with Reversible Controls

Welcome to the migration risk review on Wednesday, October seventh. I am Camila from Program Delivery. Ravi represents Platform Engineering, Eun and Lena join from Billing Operations, and Peter represents Data Assurance. Please confirm that you have the migration plan and the unresolved issue register. We are replacing a billing system that has become difficult to maintain. The objective is accurate, traceable invoicing with a manageable operating process, not simply switching off the old application on a memorable date. Today we will decide how to compare the systems, who controls invoice issuance during transition, and what evidence would justify moving the authority to the new platform. We also need a practical response if the comparison reveals a serious discrepancy.

I have both documents. The new platform can calculate charges, generate invoice drafts, and export accounting entries. We have tested the normal monthly subscription case, but some exceptional adjustments still need coverage. My team favors a single cutover because maintaining two systems increases technical complexity. However, I recognize that a clean switch in the architecture diagram can be a messy switch for the people who operate billing. I can explain the controls we have built and the limits we have not yet tested. I would like us to define parallel running precisely. If both systems send real invoices, we create a duplicate charging risk rather than a useful comparison, and that is not an acceptable form of transition.

Billing Operations has the materials. We process five thousand accounts each month in this scenario, including prorated changes, credits, and customers with unusual billing calendars. The old system is inconvenient, but staff know how to identify its limitations. With the new system, a familiar-looking total might hide a different rounding rule or treatment of an effective date. I want a shadow billing period in which the new platform produces drafts but cannot issue them. We can compare results before changing customer-facing authority. That is different from operating two independent billing processes. We also need training around exceptions, because a process that works for standard accounts but leaves staff improvising every adjustment is not ready for reliable operation.

I have the documents and have reviewed the migration dataset. There are account identifiers that changed during a previous merger, and some historical credits refer to the old identifiers. If we migrate balances without the relationship between those records, the new system could apply a credit to the wrong account or fail to apply it at all. I can build reconciliation checks, but they must use business rules approved by Eun's team. Matching row counts alone is not enough. We need to compare opening balances, transaction links, and the meaning of the imported fields. Lena has selected examples where the current records are ambiguous, which should help us decide what to repair before migration and what to preserve with an explicit limitation.

The examples include a customer whose credit was issued after an account merge, a midmonth plan change, and an adjustment entered with no explanation. I do not think we should reproduce every historical error merely to make the new totals match the old system. On the other hand, silently cleaning the data during migration would make it difficult to explain changes to customers and auditors. I suggest an exception ledger that records the original value, the approved correction, the reason, and the person who authorized it. Unexplained adjustments should be investigated, not assigned a convenient description by the migration script. We need a process for unresolved cases that does not let uncertainty disappear inside a transformation rule.

An exception ledger is feasible, and it will make the migration code simpler because we can keep corrections separate from mechanical transformations. I propose importing the last twenty-four months of detailed transactions, plus verified opening balances for older history. Older records can remain in a read-only archive with a documented retrieval route. Bringing every obsolete field into the new platform would increase complexity without helping current billing. However, we need to confirm that the archive supports customer inquiries and the organization's retention requirements. I am not proposing to delete historical information. I am proposing to separate active processing from historical reference so we do not burden the replacement system with structures that no longer serve a live business purpose.

That separation makes sense, but the retrieval route must be tested by Billing Operations, not only by an engineer who knows where the files are stored. A customer may ask about a charge from three years ago, and the agent needs to find the relevant record without opening a technical console. I also want the account mapping available in the archive so staff can follow a changed identifier. For the shadow period, we should use one full monthly cycle and a selected set of exceptional cases. A comparison using only clean accounts would tell us little about the situations that consume most of the team's attention and are most likely to create customer complaints during the transition.

I recommend comparing every active account's opening balance and monthly charge, then using detailed test cases for the exceptional rules. For each difference, we should classify whether it reflects a defect, an approved correction, or an intentional rule change. Those categories have different implications. A difference is not automatically a failure, and an identical total is not automatically a success. Two incorrect components could cancel each other out. I will compare line items and tax treatment as well as totals, using the billing rules approved for this migration. We should also verify that the accounting export reconciles to the invoice drafts, because a correct customer document with an incorrect ledger entry would still be a serious operating problem.

The current plan names November second as the cutover date. Ravi, your team wants to stop updates in the old system that morning and move all processing to the new platform. Eun wants a full shadow cycle first, which would push the authority change later. We need to resolve the sequencing rather than simply add more review meetings. Could the October billing cycle serve as the shadow run while the old system retains sole issuance authority? Then we could make a decision in early November based on the comparison. I do not want the date to become a substitute for evidence, but I also do not want an open-ended parallel arrangement with no clear owner or exit condition.

We can support an October shadow run if the new platform receives a controlled copy of the same input data. I would not connect it directly to changing production records during the comparison, because then the two systems might calculate different populations. We can freeze a snapshot, record its version, and rerun calculations reproducibly. The new platform's email and payment instructions will remain disabled. My concern is what happens after authority changes if we discover a defect. Returning to the old system is straightforward only before new transactions are accepted. Once the new platform has processed adjustments, a simple switch back could lose those changes. We need a transaction journal and a tested recovery procedure, not just a rollback button in the deployment screen.

That is the risk our operators worry about. A technical rollback that restores yesterday's database may not restore today's customer corrections. I suggest separating calculation authority from issuance authority during the first live cycle. The new system can prepare approved drafts, but a designated billing supervisor must release the final batch after reconciliation. If a discrepancy appears before release, we can hold the batch without sending incorrect invoices. After release, we need a correction process that preserves the issued document and creates a traceable adjustment. We should not overwrite an invoice that has already reached a customer. The procedure needs to state who can stop a batch and how staff communicate the delay while the issue is investigated.

I support that controlled release, but we must ensure the old system cannot also issue the same batch after the authority transfer. Staff may use a familiar workaround under pressure and accidentally create duplicates. We need a single issuance authority recorded for each billing period, with the other system blocked from sending. The operator checklist should begin with confirming that authority. I also want a dry run in which we deliberately introduce a calculation discrepancy and ask the team to hold the batch, investigate, and communicate the status. A procedure is not proven because people have read it. We need evidence that they can follow it when the figures do not match and the normal deadline is approaching.

For the authority decision, I propose four evidence requirements. Every active opening balance must reconcile or have an approved exception. The exceptional rule tests must pass, the accounting export must match the approved drafts, and the operating team must complete the hold-and-recovery exercise. We should not accept an unexplained difference merely because it falls below a percentage threshold. A small total can conceal a serious problem for one customer. Instead, every difference needs a documented classification and owner. I will provide a reconciliation report that separates cleared cases from unresolved ones. The report will identify the largest individual effects, not only the aggregate difference, so the decision makers can assess the actual customer consequence.

I will deliver the controlled snapshot process and disabled issuance configuration by Friday, October ninth, at five p.m. Asia/Seoul. I will also document the transaction journal and the conditions under which a technical rollback is safe. The recovery exercise will include restoring a test copy and replaying approved adjustments, with Peter checking that no transaction is lost or duplicated. We will not call the procedure successful merely because the application starts again. The test needs to show that balances, drafts, and adjustment history remain consistent. I will add a visible environment banner so operators cannot confuse shadow mode with the live issuance environment, and the system will block sending while that mode is active.

Billing Operations will approve the exceptional rule catalogue by Tuesday, October thirteenth, at noon Asia/Seoul. Lena will coordinate examples with the operators and identify where the current process relies on undocumented judgment. We will turn those cases into explicit decisions rather than embed someone's memory in the migration logic. I will name the supervisor authorized to hold and release a batch, plus a backup who has completed the same training. The team will test historical retrieval and account mapping before signing off the archive route. If the archive is difficult to use, we will fix access rather than declare that historical information is technically available and leave staff to struggle when a customer asks for an explanation.

I will revise the migration schedule by tomorrow, October eighth, at three p.m. Asia/Seoul. October will be the shadow comparison period, and the authority decision meeting will take place on November fourth. We will remove the unconditional November second switch from the plan. That is a sequencing change based on the evidence requirements, not permission for an indefinite delay. Each unresolved issue will have an owner and a resolution target, and I will track whether it blocks the authority change or can be handled afterward without customer risk. I will also ensure the project update explains what shadow mode means. Colleagues should not announce that the new billing system is live simply because it has started producing draft invoices internally.

I will prepare the operator rehearsal for Thursday, October fifteenth, at ten a.m. Asia/Seoul. It will include a missing credit link, a disputed effective date, and a batch that must be held because the accounting export does not reconcile. We will ask participants to use the procedure rather than rely on Ravi standing beside them. I will record confusing steps and revise the guide before the shadow cycle begins. The exercise should also include the customer message for a delayed invoice. Operators need to explain that the invoice is being checked without suggesting that payment is due on a document they have not received. Clear communication is part of the migration control, not an optional item after the technical work is complete.

I will attend that rehearsal and verify both the data outcome and the decision record. If an operator corrects a value, we should be able to see the original entry, the authorization, and the resulting balance. I will also test a failed replay during recovery to ensure the procedure stops safely rather than partially applying a batch and presenting it as complete. The comparison report will use the same account population for both systems and state the snapshot version. That makes results reproducible. If someone changes the source after we freeze it, the change must enter a later controlled version, not quietly alter one side of the comparison and create a discrepancy that looks like a calculation defect.

One remaining concern is access after the old system becomes read only. Some support scripts currently update account notes there, and disabling the interface alone will not stop those scripts. I will inventory the background jobs and integrations before the rehearsal, then disable write paths that are no longer authorized. We need to distinguish a read-only screen from a read-only system. I will also confirm that the archive retrieval service cannot trigger billing actions. That sounds obvious, but shared credentials and old automation can blur the boundary. The authority transfer will include revoking obsolete write permissions, not merely telling operators to use a different application while the old processes continue running invisibly.

Our next risk checkpoint is Friday, October sixteenth, at two p.m. Asia/Seoul, for forty minutes. We will review the rehearsal evidence, the exception ledger, the archive access test, and the inventory of background write paths. We have chosen a shadow comparison with a single issuance authority and a controlled recovery process, rather than a date-driven switch that assumes the data will behave. I will circulate the revised plan today as a draft and mark the evidence requirements clearly. Please flag any task whose completion condition is vague. At the checkpoint, we need to know what has been demonstrated, what remains uncertain, and whether the operating team can manage the new process without depending on the project's specialists for every unusual case.