Skip to main content

Upgrade FAQs

1. What should we provide to Simplanova before project?​

1.1. Database backup​

Database backup file in .bak format. We will extract all objects from this database to use them for upgrade and data migration. For upgrades from classic NAV versions 4.00/5.00/6.00/6.01/6.10 you can provide either .bak or .fbk copy of database.

1.2. Development license​

Development license should be provided if any restricted range objects are in your solution (e.g. add-ons). License should contain permissions to modify all restricted range objects. This license is a must even if restricted range objects are excluded from upgrade scope.

1.3. Add-on objects and add-on data migration toolkit​

If your solution contains any add-ons which will be upgraded to newer add-on version, we will need the following files:

  • Currently used add-on version objects in .fob, downloaded from add-on provider and uploaded separately;
  • Business Central v14 C/AL add-on files in .fob;
  • Target version add-on files in .App;
  • Add-on data migration toolkit and guidelines how data migration should be performed.

Please contact your add-on provider for the latest versions of add-on objects.

1.4. SQL server version information​

To know on which SQL version should the final database be backed up. Please clarify on which SQL version you are planning to run the upgraded solution.

1.5. Testing scenarios​

Our general testing phase consists of the following tests:

  • Running all in-scope pages (merged and custom) to review layout
  • Running all in-scope reports (merged and custom) to review layout
  • Running all in-scope xmlports created for file export (merged and custom) to review output
  • Performing generic functional testing: creation of customer, vendor, item; creation of new sales and purchase orders and posting them, etc.

Every NAV installation is different and uses some modules more than others. It is therefore encouraged to provide us some testing scenarios in order to test the most important functionalities properly. It can be guidelines on how to perform various daily tasks using your solution, files which can be used to test xmlports created for import, test scenarios that are used on your side to perform solution testing, etc. Anything you can provide will be helpful as it will ensure better solution testing before release.

If none testing scenarios are available and you cannot create them – it would be great to receive a list of frequently used objects.

2. What if our database differs from the one provided for estimate?​

Our standard approach is to compare what you have provided for evaluation with objects you provided prior the start of the upgrade. We will inform you immediately if any changes between these two versions are identified. Changes are minor and do not affect the price in most cases. However, if there are significant differences between the two versions (i.e. various new functionalities and custom objects added) – the project will be re-evaluated and we will inform you about additional effort required from our side to upgrade these additional customizations so that you can decide whether we should include them in our scope or not.

3. How will we know about the progress of our project?​

3.1. Check-in email​

At the very beginning of the upgrade project you will receive a check-in email that will contain the following information:

  • What standard NAV/BC versions we are using for your upgrade: current and target;
  • What custom objects we are migrating: provided file name and where we picked it up from;
  • What add-on versions we are using for your upgrade: current version and target; provided file names and where we picked them up from;
  • Weekly time plan to describe which tasks will we work on every week;
  • Information regarding your support period;
  • Some questions related to moving to extensions: how event subscription functions should be called, where should they be moved, etc.). Please allocate some time to answer these questions.

3.2. Weekly status updates​

Our usual approach is to provide weekly status update emails every Friday. These emails will contain the following information:

  • What tasks we have worked on during the week;
  • What issues have we faced where we need your clarification. Please allocate some time to answer these questions;
  • What tasks we will be working on next week;
  • How is our progress compared to the time plan which was provided together with check-in email;

If there are any urgent issues – we will of course e-mail you ASAP. We are open for other forms of weekly updates, i.e. having weekly calls.

3.3. Release email​

At the very end of the upgrade project you will receive a release email that will contain the following information:

  • Where release package can be downloaded from and what files it contains;
  • All notes relevant to the project, i.e. list of BaseApp modifications, list of all issues together with agreed-on solutions, etc.;
  • Information regarding your support period;
  • Guidelines how to use our support system.

4. What are our responsibilities?​

4.1. Allocate time for project questions​

Please allocate time for weekly project related questions, usually concerning reimplementation of existing functionality.

4.2. Download release package​

Please download the release package and review files to make sure that everything is OK.

4.3. Test the upgraded solution​

Please restore database and plan to test our release as support period starts immediately after project delivery. We would highly recommend to organize the testing in the following way:

  • test the upgrade release at Partner organization before releasing to customer;
  • organize additional customer testing before the production migration date.

4.4. Register support issues​

Please always use Simplanova support system to inform us about any problems. Using this system helps both sides to keep track of all issues and their status. After creation, issue will be assigned to a developer during 4 working hours. Fixed objects or our feedback regarding the issue will be provided during 2 business days.

4.5. Give us feedback​

We would appreciate any insights that you can share with us regarding project quality, management, communication and other relevant topics. Please send your feedback via email or fill in online form of customer feedback.

4.6. Re-implementation of unsupported by extensions functionalities​

There are some customizations that are not supported in extension development. All issues and possible solutions are discussed during upgrade process. Some of these customizations might end up as BaseApp modifications if there is no other way to re-implement the change. Final list of all such modifications will be provided together with release email. Please allocate some time to communicate this to the customer and review the following points:

  • Is functionality still in use, maybe it’s deprecated during product life cycle?
  • How much time redesigning this part take approximately?
  • Who and when redesign such cases?

4.7. Ask Microsoft to include new events in next cumulative update​

There are some customizations that are not supported in extensions development. All issues and possible solutions are discussed during upgrade process. Some of these customizations might be re-implemented by creating a custom event (BaseApp would be modified to add new event publisher for a standard object). Final list of all such events will be provided together with release email. In order to remove these BaseApp modifications (custom added event publishers) – it is possible to fill-in a request form and as Microsoft to add these events to next cumulative update or major release. Microsoft is usually very responsive to these requests and all needed events are created. All the information on how to create this request will be provided by us if it will be relevant.

4.8. Creating Business Central users and assigning permissions​

Please allocate some time to communicate this to the customer and review the following points:

  • Who and when will recreate this data?
  • Is all the data correct in current version?

If migrating to Business Central SaaS:

Since BC SaaS uses Azure AAD for users, you will have to create new users and assing permissions after migration to Business Central SaaS.

If migrating from NAV 7.00/7.10/8.00/9.00/10.00/11.00/13.00 to BC on-premise:

Since we are using our own server for data migration – we do not have all the users that customer has on his server. For this reason, we cannot migrate data of the following system tables: User, “User Personalization”, “User Property” and “Access Control” If there are any data in listed tables – this data will be removed before data migration. Keeping this data would cause error during data migration process. This data should be recreated after data migration.

If migrating from classic NAV versions 4.00/5.00/6.00/6.01/6.10 to BC on-premise:

Since we are using our own server for data migration – we do not have all the users that customer has on his server. For this reason, we cannot migrate data of the following system tables: User, “User Personalization”, “User Property”, “Windows Login” and “Windows Access Control”. If there are any data in listed tables – this data will be removed before data migration. Keeping this data would cause error during data migration process. This data should be recreated in tables User, “User Personalization” and “Access Control” after data migration.

4.9. Setup of Report selections​

note

Applicable for migration from classic NAV 4.00/5.00/6.00/6.01/6.10 to BC 14 C/AL only

Only data related to standard range reports is migrated for Table 77 ”Report Selections”. Migration of custom reports data is excluded from Microsoft data migration toolkits. The reason for this is that not all custom reports are usually included into upgrade scope and sometimes customer changes his mind about what report should be setup as default in report selections. Please allocate some time to communicate this to the customer and review the following points:

  • Is data in classic version correct and should be exactly the same in target version?
  • Who and when will re-enter custom reports related data into Report Selections?

4.10. Images of custom page actions​

note

Applicable for migration from classic NAV 4.00/5.00/6.00/6.01/6.10 to BC 14 C/AL only

All command buttons that were newly created by the customer in standard and custom forms are moved to target version as page actions. These custom actions will not have Image property set-up to them. Please allocate some time to communicate this to the customer and review the following points:

  • Are images necessary on custom page actions?
  • What images should be used for which actions?
  • Who and when will add these images for page actions?
  • How much time will this task take approximately?

4.11. Re-implementation of report TransHeaders and TransFooters​

note

Applicable for migration from classic NAV 4.00/5.00/6.00/6.01/6.10 to BC 14 C/AL

Transheaders and transfooters functionality is obsolete in RTC version. This functionality is removed from all standard reports by Microsoft and it will also be removed from all custom reports by Simplanova. Please allocate some time to communicate this to the customer and review the following points:

  • Are there any reports where this functionality is absolutely necessary?
  • Who and when will add this functionality?
  • How much time will this task take approximately?

4.12. End-user training and communication​

At no point will we communicate with your end-customer directly unless authorized by you. We will therefore ask you to organize end-customer training and be the first line support for any end customer questions during the upgrade project.

5. What will happen with custom/add-on objects that are excluded from our project scope?​

If there are any custom or add-on objects that are excluded from your project scope:

  • These objects will not be moved to the target version;
  • Data of excluded custom/add-on tables will be lost;
  • If any references to out-of-scope objects exist in remaining solution – these references will be commented out.

6. What will be delivered once the project is completed?​

6.1. Database backup​

Database backup file in .bak format if data migration is included in project scope.

6.2. Migrated customizations​

For Business Central AL: App file of your custom extension. This extension will also be installed on provided database.

For Business Central C/AL: solution objects in .FOB file.

6.3. Zip file of AL project​

Compressed folder of AL project will also be provided. AL project contains all of source AL objects from which app file was build, so it will be useful if you decide to modify something after our release.

6.4. Data Migration folder​

Data migration folder that contains all the files which are necessary to perform data migration:

  • Detailed step-by-step guidelines on how to perform data migration;
  • APP of extension required for data migration to extensions;
  • All tools that are used during data migration: modified data migration tools provided by Microsoft, sql scripts or other tools if required for the migration.

6.7. Release information​

See 3.3. Release email for more

6.8. Login to Simplanova Support System​

New logins will be emailed for the project manager at your organization. Up to 3 people can be assigned to one support project. Please provide emails of people who should be added to our support system for Simplanova's project manager.

Simplanova's support guide will be emailed with the release email.