Choose an accounting migration date around the work

A migration has at least two dates to understand: the accounting boundary between the old and new records, and the operational moment when people start using the new system. They may align, but the plan should explain what happens if they do not.

Xero's conversion-balance guidance, for example, calls for the prior system's trial balance from the day before the conversion date. That is a product-specific accounting boundary. Loading the file and training users are separate activities that also need dates and owners.

Ask the implementation team to name each date precisely. Avoid a calendar entry that only says go live. The company needs to know where transactions belong, when the old system stops accepting ordinary entries, and how activity during the move will be captured.

List the next reporting, payment, payroll, filing, and operating commitments that rely on the accounting process. Include the people needed to complete and approve them. A quiet sales week may still be a difficult migration week if the reviewer or system administrator is away.

Microsoft's Dynamics 365 cutover guidance recommends considering business workload, reporting periods, staff availability, dependencies, and contingency time. Use those planning factors proportionately for your system. A small ledger move and a multi-entity implementation do not need identical project machinery.

Consider whether a quarter-end or year-end boundary simplifies comparisons enough to justify the additional reporting pressure. A clean-looking date is not automatically a workable date. Select the window that lets the company establish reliable records and operate the following day.

Identify the first report or transaction process that must work in the new system. Then schedule the accepted configuration, source extraction, mapping, test migration, review, corrections, training, and final load needed to support it. Reserve review time explicitly.

Ask when source information becomes reliable. A month-end statement may arrive after the desired conversion boundary. A payroll or inventory schedule may require additional review. The plan should explain how late information is handled without pretending the old period was complete earlier than it was.

Build enough time for a failed test and a corrected attempt. If the only available window assumes every import succeeds on the first try, discuss a later date or a narrower initial scope before committing.

For a hypothetical example, a company selects November 1 as the new accounting boundary but finishes the technical load on November 3. It needs a controlled record of November 1 and 2 activity and a clear instruction about where those transactions are entered. The gap cannot be left to individual judgment.

State which system is authoritative before and after the operational switch. Identify who captures transactions during any downtime, who checks completeness, and how duplicates are prevented when feeds or imports resume.

Include late corrections to the old period. A final source adjustment may affect the opening position in the new system. Assign the person who approves the old-period change and the person who carries the reviewed effect forward, with references that allow the two records to be connected.

Get acceptance from the provider, company approver, technical owner, and any relevant connected-service team. Verify actual availability rather than assuming a vendor support desk can resolve a migration-specific issue immediately.

Check planned software updates, integration changes, and other projects that could affect the move. Avoid changing several important variables in the same window unless the combined change has been deliberately planned and tested.

Name a backup date and the conditions for using it. A date should remain a decision supported by readiness, not become an obligation to launch after a critical test fails. Communicate any change to the people whose work depends on the transition.

Record the chosen accounting boundary, operational switch, first expected output, key dependencies, and readiness decision date. Include the unresolved assumptions and their owners. The approval should make clear what must be true for the plan to proceed.

Revisit the date if source quality, scope, staffing, or business commitments change materially. Do not quietly compress validation and training to preserve a date chosen before those facts were known.

A sensible migration date is one the team can explain through the work. It provides a clear boundary for the records, enough time to verify the move, and a realistic path to the first completed accounting cycle.