How much accounting history should move into the new system?

Decide what the company needs to do with older records before choosing how much to import. A future query may require a comparative report, an unpaid invoice, a transaction's supporting evidence, or the history of a change. Those needs are not all satisfied by the same migration format.

Separate data needed for current operations from history needed for explanation or retention. Open customer and supplier items often need operational detail in the new system. Older closed transactions may be usable through an accessible archive if the company can still answer its legitimate reporting and evidence questions.

Microsoft's data-migration guidance distinguishes configuration, master data, and open transactions, and calls for a defined migration scope. Apply that distinction to the accounting history decision. Copying everything is not a substitute for knowing which data the new process will actually use.

Full transaction migration can support detailed historical queries in one place, but it increases mapping, validation, and exception work. Summarized history can support selected comparisons with less imported detail. An archive can preserve evidence without forcing old data into the new system's structure.

A mixed approach is often worth evaluating. For example, a company might move open items and an agreed set of comparative balances, then preserve older transaction evidence in an indexed archive. This is an illustrative design option, not a universal recommendation.

Ask the implementation provider to price and explain the options against the actual sources. A proposal should identify the periods, record types, dimensions, attachments, and exceptions included in each option rather than simply saying historical data migration.

Read the product's current migration documentation and ask about the exact route being used. Transactions, attachments, custom fields, audit history, recurring templates, and reports may transfer differently. A successful import message does not establish that every kind of historical evidence moved.

Intuit's US Desktop-to-Online conversion guidance, for example, identifies reports that do not transfer, including the Desktop Audit Trail, and describes other feature differences. That is a concrete reason to inspect the source and target record types instead of treating a converted ledger as a complete historical archive.

Ask for a sample covering the data you care about. Can a user find a specific old invoice, its remaining balance if any, the relevant dimension, and the supporting document? If the target contains only a summarized journal, determine where the original detail will remain and how the link will be maintained.

Identify the archive owner, authorized users, format, index, retention arrangements, and retrieval process. Preserve the context needed to interpret the data: entity, period, accounting basis, chart mapping, report definitions, and source references. A folder of unlabeled exports can be technically complete and practically unusable.

Check whether continued access depends on a paid subscription, a particular employee, or software that the company plans to retire. Test retrieval using an authorized person who did not create the archive. They should be able to locate a defined record and explain which period and entity it belongs to.

Determine retention requirements with the appropriate accounting, tax, and legal advisers for the actual records and jurisdiction. Do not assume that the software vendor's data-availability period is the company's required retention period. The company may need a different arrangement before canceling access.

Preserve records needed to explain migration transformations. If old accounts are combined or dimensions change, retain the approved mapping and reconciliation. Otherwise a later question about an older balance may require reconstructing the migration itself.

Choose representative future questions and test each against the proposed design. Include a historical comparative, an old transaction, a supporting document, and a current open item. Record whether the answer comes from the new ledger, a summary schedule, or the archive.

Check for double counting at the boundary. Historical summaries and detailed transactions must be loaded through a coherent method; importing both without the intended controls can duplicate balances. Have the responsible accountant and implementation specialist agree the treatment and verify the result.

Document the final history scope, known limitations, archive route, and ownership. Obtain acceptance from the people who will use the records, not only the person loading the data. Any excluded record type should have an understood consequence or another retrieval route.

The right history decision leaves the company able to answer its expected questions at a proportionate cost. That result matters more than the number of years displayed in the new system's menu.