Migrating Data into Business Central

Data migration is a key aspect of moving to a new system. While we always recommend minimising the amount of data you migrate, it is important to make the migration process as easy as possible. Using configuration packages is Business Central’s suggested method for moving large amounts of data. Let’s firstly run through a few key questions:

What is data migration?

Data migration is transferring data from one system to another. Instead of manually recreating all the records, we want to copy all of the record field entries and attach them to their corresponding field in Business Central. When changing systems, bringing across entities like customers, vendors and items will be necessary, unless they are out of date records with no need to come across to the new system. Moving to a new system is the perfect opportunity to ‘clean up’ your data and decide what is and isn’t required.

What are configuration packages and is this the same as RapidStart?

Data migration can be done en masse using spreadsheets. These spreadsheets are configuration packages, which are customisable templates which you fill with data you’re looking to bring across to a system. Yes, the Configuration Packages page on Business Central acts the same way as RapidStart on NAV or Navision.

Is it only static data that can be migrated?

No. Transactional data can be migrated across systems. Static data would always be the first stage, but if that’s in place, live data can be migrated in the same way.

Performing a successful migration in Business Central

Creating a Configuration Package

We now know why we use configuration packages, but how do we create, fill, export and import them? These are the four basic steps to a migration of data.

To create a configuration package, use the search icon and type either ‘Configuration Packages’ or ‘Rapidstart’. The search bar recognises where users are trying to get to when they type the latter, as you can see below:

Looking at the key fields

The next stage is to click ‘New’ and create the package. Perhaps a bit colourful but I’ve highlighted some of the key fields below:


The Code is essential to identifying which package this relates to. If we are creating a package called Item, having the Table ID set to Vendor is unhelpful. The Package Name is along the same lines, best to relate it to the Code and Table ID.

Language ID

The Language ID relates to the Windows language for the Configuration Package. For any of ours, this will be set to 2057.

Exclude Config. Tables

The Exclude Config. Tables field in all likelihood should be clicked. This will prevent extra pages being added to the Configuration Package if it’s exported to Excel. These tables are generally not added so it’s advised to enable this field.

The No. of Fields Available and Included fields below relate to the number of fields associated with the entity, so Item in our case. If we click into the figure in the No. of Fields Available or click ‘Table’ and ‘Fields’, we can see each field. Now, each entity will have a key field associated with it which won’t be toggleable. This means you can’t create a template for this without including this field. This is the ‘No.’ field in the majority of cases.

It’s unlikely all the fields will be relevant to the business in question when specifying the fields to include on the template. The ones that are however, have to be considered carefully. Remember, even if you don’t include a field on a configuration package, you can still amend that field on records manually, after applying the package. It might be that you migrate packages including the data you know is set in stone and manually enter the other data which isn’t clear now, at a later point.

Because the majority of fields are often not applicable to the business in question, we often recommend clicking ‘Clear Included’ and then manually selecting only the fields relevant to you. Once you have selected the relevant fields for you, click out of this screen.

Exporting the package

The next step will to export our package to Excel. Below is one route of exporting. An alternative is to click ‘Package’ and ‘Export to Excel’. Notice how both of these actions are done at a header level. If I were to click into ‘Excel’, on the ‘Tables’ row, I would get the same options. So what’s the difference between doing it here or at the top? The difference is at the Tables level, you’re exporting an individual line. If you perform this action at the header level, you are exporting every Line at once.

When we export the package, we will get something like this:

This is only a tiny snippet of what could be a massive amount of data. It highlights the Table name and ID at the top too. This is necessary for importing the record, so don’t delete the first two rows.

You might be wondering why there’s field data in our Excel sheet. This all depends on whether you’re migrating data which already exists in the Company in the same Business Central environment or merely the empty template which you plan on filling from data from an external source.

Filling the template with data

If you’re getting your data from another system, you will need to map which fields in the old system match those in Business Central. For example, the ‘No.’ field is likely to be the same or similar throughout all ERP systems. All the fields you use and want to continue to use will have to be matched. If there are instances where Business Central doesn’t have a field which you’d like to carry over, development may be required before the data can be migrated. Of course, in situations where Business Central has new functionality which wasn’t available in your previous system, these fields can be manually entered as you likely won’t have the data to fill the field in the package, to hand.

Importing the package

Once you have filled in the package with all the relevant records you wish to import, we need to push this data into Business Central.

When importing, click ‘Process’ and ‘Import Package’. You’ll get an option come up to choose the relevant file. After choosing the file, you should get a screen like this:

Click ‘Import’ at the top of the screen. You should be taken to the Config. Package Card screen you were on before. The ‘No. of Database Records’ field on the right side indicates how many records are in the system currently. After importing the file, the records are not active yet. So if there’s a figure in that field, it indicates records have been created prior, either manually or using configuration packages.

If at this stage you have a red text stating there are a certain numbers of errors, it may indicate, for example, that character limits have been exceeded on particular fields.

Validating the package

Next, we need to validate the records we have brought in. To do this, click ‘Actions’, ‘Functions’ and ‘Validate’ in the header section. Alternatively, click ‘Process’ and ‘Validate Package’. It’s possible (and quite normal) to get errors at this stage! Errors on validating usually mean that there are data issues. Typically, these occur where values you’ve inputted into your package don’t match the data already in the system. For example, including a Base Unit of Measure or a Country/Region code that hasn’t been set up. If you have no errors at this stage, skip the next section.

Managing errors after validating the Configuration Package

Where you do get errors at this stage, there’s a couple of ways you can manage this. The way in which you manage this will depend on whether or not your data is valid.

The data is correct but Business Central disagrees

Where your package data is in fact what you intended it to be, you’ll have to amend the setup in the Company to allow for it. For example, if there isn’t a ‘Kilogram’ Unit of Measure in the system, add it. After this, you can re-validate the package and it should remove those existing errors. Occasionally, even after clicking ‘Validate’ again, the number of errors remains the same. If that’s the case, refresh the page and it should change.

The data isn’t correct

Where your package data is invalid and the setup is correct, the data must be amended. A classic example would be that there are letters in a Mobile Phone No. field, which makes it invalid. In cases like these, we have to do four things:

  • Delete the imported records from Business Central
  • Amend the entries which caused errors in Excel
  • Import the package
  • Click Validate again

To delete the records that have been imported, click the number link in the No. of Package Records field on the Line. In there, hold the ‘ctrl’ key and click on a Line with a record in it. When you do this, a circle should appear at the top. Click this to highlight all the Lines and then click the ‘…’, ‘Manage’ and ‘Delete’. The reason we need to delete them is because, despite us not applying them to the system yet, the records are still sat there.

We need to start with a clean slate and try again. From this point, we can export the package again, make the necessary adjustments, import and validate it. Do this until there are no errors.

Finally, we have to click ‘Process’ and ‘Apply Package’. Alternatively, click ‘Actions’, ‘Functions’ and ‘Apply Package’. Once you have clicked this, the Configuration Package data will be in the system as usable data.

Concluding remarks

Thanks very much for reading; hopefully you got something out of it. Data migration is reasonably straightforward in Business Central, but using such powerful functionality always poses a risk of errors.

This is our final post prior to the Christmas break; we will be back in early January! We wish you a fantastic festive period wherever you are, however you celebrate it. And for those who don’t celebrate Christmas, we hope you have a great start to the new year.

To get in contact with us and see how we can help you, click here.