License question/issue after NAV upgrade

David_SingletonDavid_Singleton Member Posts: 5,479
I am working with a client that is in the process of upgrading. They have multiple NAV installations in multiple countries and differing versions. For a number of reasons, it looks like the best path will be to close out all the existing databases and then start each new with opening balances brought into 2009R2 databases.

The issue is that from time to time they need access to the old data, and we would manage that with a mix of Linked Views for data they access regularly (mainly sales history) and for data they access less often (like printing old sales invoices and reviewing old inventory) they will just log into the old database and check the data. To make this simpler, the plan is to do an exe only upgrade on the old databases so they can just connect in with the current client.

So now we come to licensing. How does that work. The historical database is not technically active, its just a repository of data, all processing happens in the new database, but what about when they (for example) reprint an old invoice? Do they then need to have a separate license for the old and new databases? Or can they access the data using their current license.

To add to the complication, for initial inquiries, it seems that the rules are different in different countries.

Does anyone have any experience with this. For sure this is not the first time a NAV customer has upgraded this way, so there must be thousands of cases like this out there.
David Singleton

Comments

  • bbrownbbrown Member Posts: 3,268
    In a past conversation with Microsoft, I was told that a client is allowed to maintain 1 "read only" database copy for offline reporting purposes. That being said, I've never been able to find anything in the SLA that spells this out.

    I think what you describe is a common practice with accounting upgrades, and not just NAV. Whether it's actually covered by the license is a question.
    There are no bugs - only undocumented features.
  • David_SingletonDavid_Singleton Member Posts: 5,479
    bbrown wrote:
    In a past conversation with Microsoft, I was told that a client is allowed to maintain 1 "read only" database copy for offline reporting purposes. That being said, I've never been able to find anything in the SLA that spells this out.
    Yes definitely I have heard the same, but is that world wide, or just in some countries? and also the reason I gave the example of re-printing invoices, as an example where Read only wont work.
    bbrown wrote:
    I think what you describe is a common practice with accounting upgrades, and not just NAV. Whether it's actually covered by the license is a question.
    Exactly, there must be thousands just in Navision alone, but are they legal?
    David Singleton
  • ara3nara3n Member Posts: 9,256
    I fail to see where the issue is? NAV license is concurrent users. You can have multiple databases on one server. For performance reason you can have separate database for each company.
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • bbrownbbrown Member Posts: 3,268
    Since when does NAV license allows multiple databases. The SLA states you are only allowed 1 system database.
    There are no bugs - only undocumented features.
  • David_SingletonDavid_Singleton Member Posts: 5,479
    Are you referring to the "License Per Server Granule"?
    David Singleton
  • bbrownbbrown Member Posts: 3,268
    There are no bugs - only undocumented features.
  • matttraxmatttrax Member Posts: 2,309
    ara3n wrote:
    I fail to see where the issue is? NAV license is concurrent users. You can have multiple databases on one server. For performance reason you can have separate database for each company.

    Yeah, it's very clear one database per license. Otherwise you could customize each database with different code. You might still be limited by concurrent users, but there's more than just users in that license.
  • bbrownbbrown Member Posts: 3,268
    matttrax wrote:
    ara3n wrote:
    I fail to see where the issue is? NAV license is concurrent users. You can have multiple databases on one server. For performance reason you can have separate database for each company.

    Yeah, it's very clear one database per license. Otherwise you could customize each database with different code. You might still be limited by concurrent users, but there's more than just users in that license.


    From the SLT
    User licenses are specific to a system database and may not be used with or shared among different system databases
    There are no bugs - only undocumented features.
  • ara3nara3n Member Posts: 9,256
    I didn't know that license were db specific. We implement LS Retail and each register has it's own server. My guess they have some exception.
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • David_SingletonDavid_Singleton Member Posts: 5,479
    ara3n wrote:
    I didn't know that license were db specific. We implement LS Retail and each register has it's own server. My guess they have some exception.

    LS Retail licensing is very specific, the granule "Store License is the server in each store and the POS license is the client. Because of the way its done all the granules are in the one license though, so managing it can sometimes be complex, but it give flexibility which is necessary.
    David Singleton
  • David_SingletonDavid_Singleton Member Posts: 5,479
    Its odd that only a few people are commenting on this thread, since I would have expected it to be something affecting a very large percentage of Navision users. I wonder if simply I am wrong and maybe everyone just does a full upgrade and immediately deletes the old database. Or maybe more likely that it is a can of worms that no one wants to open.

    The issue is going to get bigger, as currently many clients that I have spoken with are of the opinion that either a lot of their customizations do not suit the RTC platform, or more commonly they see advantages in the RTC that mean redesigning (aka throwing away) a lot of their Classic client customizations. Thus leading to the point of stating clean in 2009 and especially in preparation for NAV7.

    I think its time this can of worms is opened.
    David Singleton
  • Marije_BrummelMarije_Brummel Member, Moderators Design Patterns Posts: 4,262
    Until today, I´ve only done full upgrades. The only reimplementations I´ve done were going from Navision Dos to Windows.

    With the RTC I can see that a larger number of customers who are on 2.x and 3.x will reimplement rather than upgrade since the application features have just exploded and many customisations are no longer nessesairy.

    Given that fact it is important to have best practices on how to handle reading from the old database.
  • matttraxmatttrax Member Posts: 2,309
    Or maybe more likely that it is a can of worms that no one wants to open.

    You hit the nail on the head.
  • ara3nara3n Member Posts: 9,256
    I would look at it this way. NAV allows many databases, as long as they are not production db.
    So you can view those old databases as non-production db.
    Ahmed Rashed Amini
    Independent Consultant/Developer


    blog: https://dynamicsuser.net/nav/b/ara3n
  • matttraxmatttrax Member Posts: 2,309
    ara3n wrote:
    I would look at it this way. NAV allows many databases, as long as they are not production db.
    So you can view those old databases as non-production db.

    I think this is how it should work, but if I was selling licenses I wouldn't. The company is running part of their business out of that database, even if it is a really small part and only periodically.
  • bbrownbbrown Member Posts: 3,268
    ara3n wrote:
    I would look at it this way. NAV allows many databases, as long as they are not production db.
    So you can view those old databases as non-production db.


    Is that actually spelled out in the SLT? Or is it just an assumption we all tend to make?
    There are no bugs - only undocumented features.
  • David_SingletonDavid_Singleton Member Posts: 5,479
    As Bbrown says, this is just something we assume, and this client needs to know.

    The thing is that these are not backup or development databases, they are clearly a part of the customers active Navision system, even if they just reprint one invoice per year.
    David Singleton
  • matttraxmatttrax Member Posts: 2,309
    To me, if you're adhering to the licensing policy as it is written, and it is a legal document after all so it should be pretty specific, they should all be licensed for something like a 1 user Business Essentials license.
  • David_SingletonDavid_Singleton Member Posts: 5,479
    matttrax wrote:
    To me, if you're adhering to the licensing policy as it is written, and it is a legal document after all so it should be pretty specific, they should all be licensed for something like a 1 user Business Essentials license.


    Those databases are also going to have extra tables and forms at the minimum, plus other granules, so those also need to be licensed. Also Add-ons, so then add eShip and LS Retail. It soon adds up.
    David Singleton
  • Marije_BrummelMarije_Brummel Member, Moderators Design Patterns Posts: 4,262
    Is it not possible to compare this to a customer who stops using NAV? (Never happens but let's say if...).

    In that case they also go into NAV every now end then to look at old data, maybe print and invoice.
  • David_SingletonDavid_Singleton Member Posts: 5,479
    Is it not possible to compare this to a customer who stops using NAV? (Never happens but let's say if...).

    In that case they also go into NAV every now end then to look at old data, maybe print and invoice.


    That is a different situation, because they are only using the license on the old database, so there is no breach of license. In the upgrade case they would be using one icense to access two databases.
    David Singleton
  • matttraxmatttrax Member Posts: 2,309
    One thing to note in the licensing terms, Microsoft does not explicitly state what defines a production database, but we all know what that is. Now I think in this case the customer should pay for a license, even as expensive as it is. At the end of the day, even if only very infrequently, and even if only for the smallest of tasks, they are using that database for things necessary to run their business.

    The argument can be made that it is not, though. Definitions include "A system where application programs that are already developed and tested run on a regular basis." and "The system used for day-to-day business operations." Is it run on a "regular" basis? Used for "day-to-day" operations? It truly is an interesting issue and until it is challenged by either side, customer or Microsoft, you just have to do what you think is right.
Sign In or Register to comment.