Upgrade 2013 to 2016

gtr

Hello,

I converted a 2013 database as explained in https://msdn.microsoft.com/en-us/library/dn271649%28v=nav.90%29.aspx?f=255&MSPPError=-2147217396

As explained in https://msdn.microsoft.com/en-us/library/dn271652(v=nav.90).aspx, I exported the objects of 3 databases (2013 std, 2013 modified, 2016 std) in text format.
Then I used powershell to analyze the differences :
Merge-NAVApplicationObject -OriginalPath .\ORIGINAL -TargetPath .\TARGET -ModifiedPath .\MODIFIED -ResultPath .\RESULT
Then I generated one file from the text files in RESULT :
Join-NAVApplicationObjectFile -Source .\*.txt -Destination xxx\allappcodemerged.txt

In the article mentionned above it is said that :
"You can import all objects in the RESULT folder into the new Microsoft Dynamics NAV 2016 database, or you can analyze the conflicts before you import the objects."
I want to import in the new 2016 database.


Now, when I import the file in the converted database, I have the 2 following problems :


1) when coming to 2016 standard objects that do not exist in the converted database :

For exemple : You do not have permission to create the 'Create recurring Sales Inv.' Report.


2) Another probleme occurs for 2016 standard tables that exist in the converted database but where a new field has been created in 2016 :

For exemple : Your program license does not allow you to create the VAT HEME field in the Country/Region table.


So How can I import the text file (that I generated as suggested by MS) into the converted database ?

Thanks !

jglathe

Hi gtr,

well... permission issues are commonplace for us non-MSFT developers Disclaimer: I don't use the merge cmdlets, I do the merge with source control (mercurial). The issue is the same, though. You need to have all new created objects in the standard range (..49999|100000..) in the target database. And you need to have all newly created fields in the standard range in the tables of the target database. Also, it is a good idea to exclude all system tables from your text merge, if appropriate.
There are some additional issues:
1. It is not uncommon that you have deleted fields in the standard range of standard tables. You can't delete them in the text merge, though (a good source control system does this). You need to have them in there, disabled, for the text import. Or, if possible, you build a migration table: The new table with all your custom fields, save it as .fob, import it in the target database (sync to "later"). Afterwards you can import the text file without the deleted old field. This only works when you have a clean-room version of the new table with all the AddOns that you need (also new version). Otherwise you are definitely left with non-deletable, disabled old standard or AddOn fields.
2. If your target system doesn't have all the .net assemblies, you are left with uncompileable objects (like, Outlook Integration). If they have no changes, replace them with the standard .fob version. If they are merged, you need to go looking for the .net assemblies and install them.

Overall, this process can take some time. I calculate at least a day for this stage alone.

with best regards

Jens

gtr

Hi,

I thank you for your explications
Its my first upgrade so sorry about all this questions

After database conversion I get a database - lets call it D1
D1 does not contain NEW 2016 tables and does not contain NEW 2016 fields in existing tables
So if I cannot import this 2016 standard tables and fields - whats the purpose of D1 ?

I understand you in the right way I have to take a standard 2016 database and there yes I can import my code text files.
But if so I can't see the purpose to make a database conversion.

Best Regards

jglathe

Hi gtr,

there is... for the data migration itself. You do the new/merged object set before you have a need for the converted data, sort of. D1 is your testbed for the complete NAV2016 object set with all your modifications.

with best regards

Jens

gtr

OK - Thanks !