Paragraph 17 of the Canada Revenue Agency's circular on electronic record keeping is easy to skim past. It says that when backups are your way of keeping old records, the label should name the software and version that created them, and that software and its operating system need to be available to restore the files. It's a dry instruction from 2010. It also settles a question every ERP migration reaches sooner or later: how much of the old system has to come with you?
The law's answer is narrower than most migration plans. Your records have to stay readable. They don't have to live in your new ERP. That gap, between what you're required to keep and what you choose to carry, is where a system swap turns into a manufacturing transformation.
What does manufacturing transformation have to do with legacy data?
A migration is the one point in a system's life when every inherited habit has to justify itself. Legacy ERP data is full of those habits. A part-numbering scheme can encode how the plant was organized when someone designed it. A status code can exist because a workaround once needed a name. A notes field can spend a decade doing the job of a field nobody built. Carry all of it across unchanged and the new system inherits the old one's logic along with its records.
In Odoo, that inheritance has a specific cost. Structures that don't fit standard fields tend to come back as custom development, and Odoo's upgrade documentation is plain about the consequence: a database with custom modules can't move to a new version until those modules have been made compatible with it. Odoo's guidance on upgrading customized databases goes further and tells teams to challenge their customizations and strip out anything the standard product already does. Transformation is mostly a series of decisions about which old ways get to survive, and the migration file is where those decisions get written down, whether or not anyone treats them as decisions.
How much historical data should move to a new ERP?
For most manufacturers, the new system needs opening positions and live work. Years of closed transactions can stay behind.
Odoo's accounting onboarding is built around this. The getting starteddocumentation walks through importing an opening trial balance as a journal entry, then open customer invoices and vendor bills whose totals match receivables and payables on that trial balance, then an opening inventory count. That's the financial position the system starts from. Add the master data still in use (active products, current bills of materials, work centers, live customers and vendors) plus open sales, purchase and manufacturing orders, and you have what Odoo runs on.
A simple line separates the two. Active data is anything the new system has to act on: open orders, current bills of materials, balances, stock on hand. Archive data is anything you might need to look up but will never need to change.
The awkward cases sit right on that line. A discontinued component referenced by an open order comes across, because the order does. Once the order closes, the component can be archived in Odoo instead of deleted: it drops out of everyday views, stays in the database, and comes back into any search through the "Include archived records" option in Odoo's custom filters.
Sorting every record in the old system comes down to one question.
The middle box is where most of the negotiation happens, because "we might need it someday" is how archive data talks its way into a migration file.
What do Canadian record-keeping rules require when you switch ERP systems?
The CRA requires business records to be kept for six years from the end of the latest year they relate to, in an electronically readable format, with access preserved when your systems change. None of that requires moving them into the new ERP.
The CRA's electronic record-keepingcircular, IC05-1R1, gets specific. Records kept electronically have to stay electronically readable for the full period, even if paper copies exist. When a business system changes, the ability to access and retrieve the data has to survive the change, and the changes themselves should be documented in order. Copies provided to auditors are expected in a non-proprietary, commonly used format that CRA software can process, and before a new system goes in, the CRA expects you to confirm it can export the information it needs in that kind of format. Converting records from one format to another is allowed, provided nothing relevant to taxes is lost or altered along the way.
Two practical points follow. A backup of the old database only works as an archive if you can still restore it, which is exactly what paragraph 17 is guarding against. For many manufacturers, exporting closed history to open file formats, with a written layout for each file, is simpler than keeping a legacy server alive for six years. The circular also says it doesn't reflect record-keeping rules under other federal, provincial or municipal statutes, so those need their own check.
There's a second clock running next to the CRA's. Canadian Manufacturers & Exporters reported that one in four Ontario factory workers was 55 or older in 2024, and projects an average of about 22,500 retirements a year in the province's manufacturing sector through 2033. For a legacy system, the most complete data dictionary is sometimes a person: the planner who knows what a part-number prefix used to signal, or the controller who remembers why an account was split years ago. An archive only stays useful if someone can still read it, and those conversations are easiest while the people are still in the building.
What does a disciplined migration scope look like?
A good migration scope is short, dated and argued over early. The details vary by plant, but the same few decisions come up every time.
- A cut-off date set before mapping starts.
Migrate balances and open items as of that date. Anything closed earlier goes to the archive unless someone makes a case for it.
- A record of what each legacy field does in practice.
Ask the people who use each field daily what they rely on it for, and write it down while they're still around.
- A rule for inherited codes and workarounds.
Map each one to a standard Odoo field, rebuild it as configuration, or leave it in the archive. Custom code comes last, since every custom module has to be carried through each upgrade.
- Legacy identifiers carried over as External IDs.
Odoo's import tool can reuse IDs from your previous software, so records in Odoo can be matched to their history in the archive.
- An archive tested before the old system goes dark.
Run the kind of lookup an auditor might ask for and confirm the files make sense without the old software.
These decisions come before any import file gets built, which is why scoping belongs at the front of an Odoo implementation rather than the end. For the mechanics of moving the data itself, Kodershop's guide to migration in Odoo covers both transaction-driven and table-driven approaches.
Transformation has an end date
Manufacturing transformation usually gets described as something you add: new software, better visibility, AI on top. A migration is where you subtract. Every record left in the archive is a piece of the old operating model that won't shape the new one, and every workaround you decline to rebuild in custom code is one less thing to carry through each upgrade.
The six-year rule adds a final turn: it gives the archive an end date too. A manufacturer on a calendar fiscal year that goes live on Odoo in 2026 can expect routine records from its last pre-Odoo year to reach the end of their retention period at the close of 2031, unless they relate to something still in play, such as an asset still on the books. After that, the old system stops being a dependency and becomes history. That's a finish line no go-live date offers.
FAQ
- How many years of data should we migrate to a new ERP? It depends on what the new system has to act on. A common approach is to migrate opening balances, open transactions and active master data as of a cut-off date, then keep closed history in a read-only archive for the retention period.
- Do we have to keep our old ERP running for the CRA? Not necessarily. Records must stay accessible and electronically readable for six years from the end of the latest year they relate to. Two routes are consistent with CRA guidance: keeping backups of the old system restorable, which means keeping its software and operating system available, or converting records to open formats without losing information relevant to taxes. Confirm the approach with your accountant.
- Can Odoo hold our historical records if we decide we need them? Yes. Odoo's import tool can bring records in from previous software and keep them linked through External IDs. The question is whether that volume, and the legacy structure that comes with it, is worth carrying into daily operations.