GP2010R1 to R4 upgrade process

  • GP2010R1 to R4 upgrade process

    Posted by DSC Communities on December 2, 2016 at 11:53 am
    • Brian Gale

      Member

      December 2, 2016 at 11:53 AM

      Hello everyone,

      I have an upgrade related question for GP2010.  We are currently running GP2010 R1 and are looking at upgrading to GP2010 R4 but we are not sure of what the upgrade process is.

      Can we go straight from GP2010 R1 to R4 or do we need to install R2 and R3 before R4?  Also, is there any hotfixes we need to install before R4?

      Part 2 of this question is related to the SQL side of things – will this upgrade allow us to take SQL out of compatibility mode 90?  We are currently in mode 90 and the Microsoft SQL Server Data Migration Assistant tells us that we cannot get out of 90 until a LOT of objects are fixed most of which appear to be GP objects (ie not customized stuff by us).  Some are just recommended changes, but some are breaking changes.

      Our end goal is to upgrade to GP 2016 and SQL 2016 (native 2016, no compatibility mode); the R1 to R4 is step one in this upgrade process.

      Thanks for the help.

      ——————————
      Brian Gale
      DBA
      Vecima Networks Inc.
      Saskatoon
      ——————————

    • Lou Spevack

      Member

      December 6, 2016 at 10:17 AM

      You should not be focusing on GP2010 R4.  Instead you need to research the best upgrade path directly to GP2016.  This will probably involve 4 or 5 version jumps.  If you are not very familiar with the GP upgrade process, I would strongly advise working with a partner who has done at least a few of these complex upgrades, at least for the planning phase. 

      You do not need to fully feature test each conversion jump.  What I do is only validate the data conversion with before and after reports and then move on to the next jump.  I don’t deploy clients until the last conversion is complete.  You also need to check with each ISV partner to determine the best upgrade path for each add-in product you use.

      Good luck.

      ——————————
      Lou Spevack
      Systems Accountant | Dynamics Credentialed Professional
      American Council on Education
      Washington DC
      ————————————————————————-

    • Charles Allen

      Member

      December 7, 2016 at 7:42 AM

      Service packs are cumulative. You can install R4 without installing the updates in between. These releases for 2010 are service packs for the purpose of installation. 

      For SQL, I’ve always set the compatibility level in accordance with the version of SQL Server. I’m not aware of any differences between R1 and R4 in this regard. 

      ——————————
      Charles Allen
      Senior Managing Consultant
      BKD Technologies
      Houston, TX
      ————————————————————————-

    • Blair Christensen

      Member

      December 7, 2016 at 10:08 AM

      Part of the Jump to get to 2013 goes through at least 2010 SP3.  Did that a year ago.  Then you have to go to 2013 R2.  But don’t ever overlook an upgrade as just a step to get to the next one.  Test each one individually and make sure things work.  The people that say that you don’t have to test or that you can just move along are just ignoring good practice altogether in favor of the latest and greatest.  Your business continuity is far more important than getting software X upgraded.

      ——————————
      Blair Christensen
      Database Administrator
      Oppenheimer Companies, Inc.
      Boise ID
      ————————————————————————-

    • Lou Spevack

      Member

      December 7, 2016 at 10:37 AM

      The reason I test only interim data conversion success on an upgrade with multiple conversions is that full feature testing takes too much time.  Assuming you are doing your upgrade in a test environment first (a critical requirement) and making backups all at each conversion step, you can fully test functional features after the final jump.  If you find issues, you can research them end often fix the problem without going back.  If you do isolate the issue to a specific conversion, you can restore back to that point with a fresh client and fix it, and build the fix into your production deployment plan.

      I did a number of these complex conversions when I was a partner.  None of my clients had the staff, resources or budget to cover full feature testing on a 4 or 5 conversion upgrade.  The bottom line is plan well, use a test environment and make golden backups.

      ——————————
      Lou Spevack
      Systems Accountant | Dynamics Credentialed Professional
      American Council on Education
      Washington DC
      ————————————————————————-

    • Jen Kuntz

      Member

      December 7, 2016 at 11:12 AM

      Hi Brian,

      Just to clarify a couple of terminology things… there is no such thing as R4. The “R2” releases you see with GP 2010, GP 2013, GP 2015 and now GP 2016, are specific mid-release major service packs that include new features as well as regular fixes. Anything other than the first release of the products and the “R2” release of the products are simply referred to as service packs. (SP4 for instance is what you are referring to as R4 I believe).

      Within a product release version, service packs are cumulative so there is no need to install SP2/3 before SP4. In literal terms, most people don’t refer to this as an “upgrade”, but simply a service pack installation. The “R2” releases are more significant but still not generally referred to as an “upgrade”.

      Planning and testing is always important, with any installation whether it’s a service pack, a mid-release like R2 or an actual version upgrade, but the extent of testing is vastly different when moving from one version to the next. Unless you have significant customizations in place, most clients don’t go to a super extensive level of planning on a service pack release because they are relatively straight forward most of the time. Do test service packs in a test environment if you have one, that’s always a good approach.

      SQL compatibility mode is published per version, you can search for what versions of SQL match your intended upgrade or service pack level but it’s safe to assume it won’t change until you change major versions (GP 2013/2015/2016).

      If you intend to go to GP 2016, from any version, the upgrade paths are published in terms of from what version and SP level and to what version and SP level you can go from/to. You will need to go from GP 2010 to something else before going to GP 2016 – in terms of literal technical upgrade paths, because you can’t go straight from GP 2010 to GP 2016. There are options and I recommend having conversations with your VAR about the approach and options.

      Hope that clears some things up.

      jen

      ——————————
      Jen Kuntz, CPA, CGA
      Microsoft MVP, Business Solutions
      Kuntz Consulting Inc.
      Cambridge, ON, Canada
      ————————————————————————-

    • Bruce Strom

      Member

      December 7, 2016 at 2:53 PM

      I didn’t read the other responses closely.

      We will be doing this, we will go to GP2010 SP4 first, this is required.

      You can only jump two versions in an update.

      Since our databases are large, we will jump first to GP2013 R2, and to GP2016 a week or two afterwards.

      There are a lot of large table conversions in GP2013, including GL, AP, POP, and SOP.

      If your databases are small, you can do both conversions in a weekend.

      ——————————
      Bruce Strom
      Programmer
      Associated Grocers of Florida
      sunrise FL
      ————————————————————————-

    • Beat Bucher

      Member

      December 8, 2016 at 9:03 AM

      Hi Bruce,

      research carefully all the blog posts from the GP Dev team when doing the various upgrades, because when not doing a ‘maiden’ installation, some of the security roles & tasks are _not_ created when doing upgrades. Depending on which features you may or may not use in GP, this is going to have an impact on you to grant access permissions. Check also for 3rd-party products security.

      Good luck with your upgrade project.

      ——————————
      Beat Bucher
      Business Analyst, Dynamics GP MVP
      Ultra-Electronics Forensic Technology Inc.
      Montreal QC/Canada
      +1-514-489-4267
      @GP_Beat http://dyngpbeat.wordpress.com/
      Montreal QC GPUG Chapter Leader
      GP2013R2 / MR2012 CU14
      ————————————————————————-

    • Brian Gale

      Member

      December 16, 2016 at 10:28 AM

      Thanks everyone for the input.

      I did word that wrong; it should have been SP4 not R4.  Sorry about that.

      And our end goal is to get to 2016, but we need SP4 on 2010 before we can go much further.

      The other fun bit is our DBA (me) noticed that the SQL Server is running in compatibility mode 90 (SQL 2005) on the 100 (SQL 2008 R2 in our case).  Running the SQL Data Migration Assistant indicated that a LOT of objects (nearly 7000) would need to be updated before we could upgrade to 2016.

      So our plan is to get SP4 on there and see if that number goes down.  If it does, we are happy then we are going to 2013 and repeating the task and HOPING that there are 0 or near 0 (might still be some due to customizations we have done).  But if we are still around the 7000 mark, we might need to do some tweaks to the database before we can upgrade to 2016 (both for GP and SQL).

      ——————————
      Brian Gale
      DBA
      Vecima Networks Inc.
      Saskatoon
      ————————————————————————-

    • Brian Gale

      Member

      February 7, 2017 at 12:53 PM

      So the upgrade to SP4 went smoothly.  But the data migration assistant is still grumpy about the SQL upgrade.  We appear to have some databases stuck running on SQL 2008 R2 in compatibility mode 90 (SQL 2005).

      Does anyone know if this will be an issue or if we can safely update from GP 2010 SP4 to GP2013?
      Following this update, the plan is to update the SQL server from 2008 R2 to 2012.

      Once we get GP2013 stable, we will be going to 2016 for both GP and SQL server.

      Is our current setup, SQL 2008 R2 in compatability mode 90, going to be an issue for upgrading from GP2010 SP4 to GP2013?

      Thanks,

      ——————————
      Brian Gale
      DBA
      Vecima Networks Inc.
      Saskatoon
      ——————————
      ——————————————-

    • Rob Klaproth

      Member

      February 7, 2017 at 1:00 PM

      SQL compatibility modes are just versions of where your database started from generally.  When you upgrade to a new version of SQL you are supposed to go into the properties of the database and change the compatibility mode to the new version of SQL.  I always do when I upgrade my client’s systems, so if they are going from 2008 to 2012, after upgrading to SQL 2012 I change their compatibility to 2012.

      So, if you are in fact on SQL 2008 and some of your GP databases are still in 2005 compatibility mode, just right click on the DB, go to properties, and options and change the compatibility to 2008 and hopefully GP utilities will stop complaining.

      Rob

      ——Original Message——

      So the upgrade to SP4 went smoothly.  But the data migration assistant is still grumpy about the SQL upgrade.  We appear to have some databases stuck running on SQL 2008 R2 in compatibility mode 90 (SQL 2005).

      Does anyone know if this will be an issue or if we can safely update from GP 2010 SP4 to GP2013?
      Following this update, the plan is to update the SQL server from 2008 R2 to 2012.

      Once we get GP2013 stable, we will be going to 2016 for both GP and SQL server.

      Is our current setup, SQL 2008 R2 in compatability mode 90, going to be an issue for upgrading from GP2010 SP4 to GP2013?

      Thanks,

      ——————————
      Brian Gale
      DBA
      Vecima Networks Inc.
      Saskatoon
      ——————————

    • Brian Gale

      Member

      February 9, 2017 at 3:19 PM

      Thanks.
      I do know how to change the compatibility mode, but what concerns me is that Microsofts Data Migration Assistant tells me thatthereare breaking changes due to “Following unsuported system and extended stored procedures cannot be used in database compatibility level 100 and above” and “SQL Mail has been discontinued starting from SQL Server 2012” and “RAISEERROR calls like the below example are termed as legacy-style because they do not include the commas and parenthesis” and “Non ANSI outer join operations (“*=” or “=*”) are not supported and will not work in compatibility levels 90 and above” and “Constant expressions are allowed (and ignored) in the ORDER BY clause when the database compatibility mode is set to 80 or earlier.  However, these expressions in the ORDER BY clause will cause the statement to fail when the database compatibility mode is set to 90 or later.”

      I just don’t want to change it to 100 (SQL 2008) and then have GP start giving odd results and/or failures.
      On top of the above errors, it also tells me there are a behaviour changes and depricated features.
      Going through these manually will take months.  That being said, I am also uncertain if these were GP created stored procedures or if they were user created.
      stored procedures name examples I see are smRuleSendMail, smRuleTestSendMail, SVC_Print_Call_HTML, SVC_Print_HistoryCall_HTML, SVC_MailProcessHISTORY, SVC_MailScanner and more.
      Should I be concerned about these?

      ——————————
      Brian Gale
      DBA
      Vecima Networks Inc.
      Saskatoon
      ——————————
      ——————————————-

    • Blair Christensen

      Member

      February 10, 2017 at 10:56 AM

      Sorry to be late to this party, but I’ll chime in given that I made the jump from 2010 R1 to 2013 only two years ago.  We’ve been running GP for 20+ years, so we have the definition of a legacy system!  I tested for three months my path from 2010 to 2013R2 which involved one intermediate step at 2010R3.  I had to resolves several issues along the way.  We weren’t changing database versions however, as we were already on SQL Server 2008.  What I might try if I were you is to treat the software upgrade and the SQL Server compatibility version as two completely separate upgrades to worry about.  Here’s why:

      Just a couple of months ago we moved our entire Dynamics 2013 system (and all other company SQL Server databases) to a new server VM.  In the process, we made two major changes: one was going from SQL Server 2010 to SQL Server 2014 and the other was a collation change from the original case-sensitive Dynamics collation to the newer non-case-sensitive collation standard (because nobody builds GP add-ons that actually work with case-sensitive collations).  It was a major task, but the collation change went well.  We ran into problems with the compatibility version however – not with Dynamics GP, but with a custom application.  We fought with poor performance for several weeks before backing off on the compatibility level and voila – everything worked again performantly.  My caution is that that compatibility level matters – but not necessarily to GP.  Make sure to test for collateral damage  😉

      And I wouldn’t make your focus on getting onto the latest version of Dynamics.  Business continuity is WAY more important.  Make sure that you upgrade because the features are ones you want – because they enhance your business processes.  Getting caught up in the perpetual upgrade cycle isn’t what pays the bills (unless you’re Microsoft).

      ——————————
      Blair Christensen
      Database Administrator
      Oppenheimer Companies, Inc.
      Boise ID
      ——————————
      ——————————————-

    • Brian Gale

      Member

      February 10, 2017 at 4:21 PM

      Thanks for the tip.  I bit the bullet and changed it on one of our test instances and with a very brief look at GP it appears that it is stable and running happily.

      I did not test all features yet though.  But it is one small step for our upgrade.

      ——————————
      Brian Gale
      DBA
      Vecima Networks Inc.
      Saskatoon
      ——————————
      ——————————————-

    • Brian Gale

      Member

      August 2, 2017 at 4:43 PM

      We just finished our jump from GP2010R4 to GP2016 (with a brief stop at GP2015) and it went fairly smooth.  Few little hiccups along the way, but overall was a pretty painless upgrade.

      Thanks everyone for the tips and help.
      I did hit one snag, but going to make a new post for it as it is a little unrelated to this.

      ——————————
      Brian Gale
      DBA
      Vecima Networks Inc.
      Saskatoon
      ——————————
      ——————————————-

    • Rob Klaproth

      Member

      August 3, 2017 at 10:56 AM

      I am a bit late coming back to this party but I had to take a break for a while in the forum as my workload did not really provide time for me to participate as actively as I was before.  🙂

      In all the years of doing upgrades for GP I have never used the database compatibility assistant or any other similar tool from Microsoft and have yet to see any issues.  If you run the tool against your older version of GP you will most likely get several errors that won’t show up in the newer one.  

      Changing the the compatibility mode is a requirement for GP 2016 since it does not support SQL 2008 so if you leave it in a 2008 or older mode when you run GP utilities to upgrade you will get an error.  

      For the most part the only time you may have to be concerned is if you have custom code that a developer wrote for you and it has not been updated.  Doing a test upgrade on a test virtual machine is always your best bet to insure a successful upgrade.  

      I’m glad that your upgrade went smoothly.

      ——————————
      Rob Klaproth
      Sr. Dynamics GP Consultant
      Armanino
      San Diego CA
      ——————————
      ——————————————-

    DSC Communities replied 7 years, 5 months ago 1 Member · 0 Replies
  • 0 Replies

Sorry, there were no replies found.

The discussion ‘GP2010R1 to R4 upgrade process’ is closed to new replies.

Start of Discussion
0 of 0 replies June 2018
Now

Welcome to our new site!

Here you will find a wealth of information created for people  that are on a mission to redefine business models with cloud techinologies, AI, automation, low code / no code applications, data, security & more to compete in the Acceleration Economy!