mibuso.com
Home› NAV Three Tier
Options

Smoothly upgrade 2009 classic to at least 2013 R2 RTC

Jan_VandrommeJan_Vandromme Member Posts: 6
edited 2015-08-18 in NAV Three Tier
We are planning to upgrade from NAV 2009 SP1 Classic to a NAV RTC release, at least 2013 R2, but 2015 is prefereable. What we want to skip is the 2009 RTC release because of the huge amount of problems with this release (performance wise, UI wise, ...). We would like to move to 2013 R2 RTC at least.
The main problem is how to do this while some departments are still using the NAV 2009 Classic release, while other departments already use migrated modules on 2013 R2 or 2015 RTC, working with the same data. The "same" data does not have to be stored in the same database. I mean: if there is a solution based on synchronisation, replication or interfacing between 2 databases (one on NAV 2009 and the other one on NAV 2013 or 2015), then we can accept such a solution. Is there some SQL Server technology that can be used to handle this (Log Shipping, Merge Replication, ...)?
Hardware and/or system software is not an issue. If required, it can be bought and installed.

FYI: The ERP implementation contains lots of customized modules, built with customized objects :
- about 700 new tables
- about 700 new forms
- about 100 new codeunits
- only a few (let's say 30) new reports.
- no dataports
- 3 xmlports
We were building this customized solution during the last 5 years (just started at the moment the Belgian 2009 RTC was introduced. Because of the tons of problems with this release, the customer could not accept building his ERP implementation based on it and requested us to continue on classic client at that time). Now, time has come to move forward... RTC is already much better and acceptable.

Comments

  • Options
    defiant701defiant701 Member Posts: 79
    The main problem is how to do this while some departments are still using the NAV 2009 Classic release, while other departments already use migrated modules on 2013 R2 or 2015 RTC, working with the same data.

    I'm not sure why you want to do it that way. Why is it not possible to go for the recommended way of upgrading?

    regards
    defiant701
    Debuggers don't remove bugs, they only show them in slow-motion

    LinkedIn
    XING
  • Options
    Jan_VandrommeJan_Vandromme Member Posts: 6
    Yes, you understood the question very well !
    It really will take a huge amount of time to migrate all 700 forms to pages (and that few reports, and also some table and codeunit functions changing from currform.run to currpage.run) and get it all tested again before going to a live RTC environment. There are quite some very "special" forms with master-detail-details, special matrix forms, ... that have to be redesigned, not only just because of the new UI, but also because of the new limitations of the RTC UI and the need for a better graphical UI for those parts. For some of them, I also think we will need some new Add-ins, graphical tools, ... I estimate the whole migration process at about 9-12 months of work! If we could to it more gradually, customer would appreciate it.
  • Options
    defiant701defiant701 Member Posts: 79
    Ok understood around 1.600 objects are quite heavy. I think a solution would be very difficult if you want to have 2 different (even quite similar) business logic's to manipulate your data. So synchronizing of direct NAV tables might also be difficult and might require additional import/export tables (also regarding unicode transformation).

    If you do not have the time to do the migration as "big bang" you can think of step-by-step migration similar to a cut-over planning with a new database. Here you can start to stop the internal interfaces for the sub-ledgers implemented. You can start with the general ledger first and keep supply chain and sales 100% in the legacy system and just post the g/l entries via import/export batch run (Oracle does the same in normal operation :-). Each completely upgraded module can be migrated to new system.

    KR
    defiant701
    Debuggers don't remove bugs, they only show them in slow-motion

    LinkedIn
    XING
  • Options
    Jan_VandrommeJan_Vandromme Member Posts: 6
    Another option I was thinking of, is to create a new database for the NAV 2015 RTC, while the existing database remains for use of NAV 2009 Classic.
    Since most of the modules I use, developed, ... for this particular ERP project, I do not post any ledger entries (item, g/l, customer, vendor), I was thinking about recreating the tables from the NAV 2009 Classic, as Linked Table into the NAV 2015 RTC.
    e.g. NAV2009.[Table1]. In database NAV2015, first I will create a Linked Server to the database NAV2009. Then in database NAV2015, I just create a SQL Server view NAV2015.[Table1] as select * from NAV2009.[Table1]. Then, in NAV2015 Development Environment, I create or change the Table Object [Table1] as Linked Table.
    Doing so, I guess NAV2015 will still work with the real-time data of NAV2009, as well for reading, inserting, updating and deleting.
    Then, I can migrate most of the modules to NAV2015 (as long as they do not post any ledger entries), while the posting modules remain on NAV2009. The posting modules can then be migrated in one 'big bang' (but this will still be much smaller than everything at once).
    What's your opinion?
  • Options
    defiant701defiant701 Member Posts: 79
    Hm might work but I don't think I would try this in real production :shock:. It might be interesting what's your gained experience is. By the way you might also cause a license issue when doing so.
    Debuggers don't remove bugs, they only show them in slow-motion

    LinkedIn
    XING
Sign In or Register to comment.