If you are on D365FO on version below 8.0 then you are probably wondering about your last D365FO upgrade to 8.1 and then 10.x and beyond.

 

Term upgrade is used when upgrading to Dynamics 365 for Finance and Operations from earlier version.

 

Let us now discuss what all is involved in upgrade. Below are some of coverage areas one needs to factor:

  • Prerequisite
    • Upgrade plan
    • Environment
    • ISV/AppSource readiness on 8 or higher version.
    • Code upgrade (this is done before data upgrade)
      •  
      • Overlayered and extension-based code
      • Data upgrade (this is done after code upgrade)
      • Mini UAT (User acceptance test)
        • Testing ISV impacted functionalities
        • Testing existing day to day activities
        • Checking in LCS issue search for potential issues in 8.x and possible solutions in 8.x or 10.x
        • Plan to request MS to backport 10.x fix to 8.x for critical issues (e.g. Project Quotation resend)
        • Involvement by end users: low to medium

 

Note: The above is specified in a sequence and found it to be highly effective.

  

Upgrade to 8.0 from previous version means covering your code and data from all sides.

Let us now discuss sequence of steps involved in CODE Upgrade to 8.x:

  • First get latest ISV code base compatible with 8.x
  • VSTS branching
    • Branch your existing one to a new one where the extensions and latest ISV code needs to be made available.

  • LCS code upgrade service
    • This would remove metadata hotfix’s on earlier version code base.
  • Over layering to extension – manual effort
  • LCS tickets with MS for resolution on opening point within D365FO if not available
  • Finding workaround if timing is a constraint.

Let us now discuss sequence of steps involved in DATA Upgrade to 8.x:

  • Refresh production database to your sandbox (tier2 – multi box using Azure SQL)
    • Use ‘Move database’ option inside your tier2-sandbox.

  • Then use option ‘Refresh database’ **

  • Select your production environment as source and click submit.

 

**Note during database export and import won’t bring the below things:

  • Email addresses in the LogisticsElectronicAddress table.
  • Batch job history in the BatchJobHistory, BatchHistory, and BatchConstraintHistory tables.
  • SMTP password in the SysEmailSMTPPassword table.
  • SMTP Relay server in the SysEmailParameters table.
  • Print Management settings in the
  • PrintMgmtSettings
  • PrintMgmtDocInstance tables
  • Environment-specific records in the SysServerConfig, SysServerSessions, SysCorpNetPrinters, SysClientSessions, BatchServerConfig, and BatchServerGroup tables.
  • Document attachments in the DocuValue table.
  • All users except for the administrator will be unavailable.
  • All batch jobs are set to Withhold status

 

Refer for latest and more details https://docs.microsoft.com/en-us/dynamics365/unified-operations/dev-itpro/database/database-refresh

  • Once DB is refreshed in tier2 sandbox
  • Refer for latest and more details on https://docs.microsoft.com/en-us/dynamics365/unified-operations/dev-itpro/database/export-database

  • There may be additional components in use in your environment which require further steps to upgrade.

    • Code movement from Tier1-Dev to Tier2-Sandbox
      • Prepare your 8.x package here for deployment to another environment.
      • *Note: You may choose to skip build environment deployment considering ongoing work for pre-8.0 environment.
      • Once needs to do a code freeze on your pre-8.0 environment before calling your 8.x build code as golden code base.
      • Optionally if you have already done code freeze on pre-8.0 then you may deploy a new build box with 8.x application base.
      • Once tier1-dev environment is validated and tested the code is now ready to be deployed to your tier2-Sandbox.
      • In tier2-environment, we need to set it up for target 8.x version with a new name from LCS – environment management.

    Note:

    • You are given a total of 10 days to review in TEST ad sign off before it is rolled back.
    • Also the URL remains same even though they are separate environments.

  • Once your new tier2-sandbox environment is ready you can perform below steps in sequence:
    • Apply updates
    • Upgrade database.

      • Let’s say your UAT goes fine, then you can commit your tier2-sandbox.
        • In case of issues, you may initiate rollback.
        • Also remember to perform these additional steps
          • Refresh data entities
          • Reinitiate/redeploy all BYODW and AXDW jobs
          • Validate all integrations touch points.
          • Validate all ISV settings.

       

      • Production environment upgrade
        • Similar steps are needed for production environment upgrade as tier2-sandbox.
        • Here unlike DB refresh in tier2-sandbox, no data is expected to be lost.
        • I suggest timing your cutover/downtime for a day or two for production upgrade and do it over a weekend to minimize system availability for business use.
        • In one of my upgrades, even on production we initially controlled access to select few to confirm everything is fine and later restored access to usual way.

       

       

      #One last thing in case your build box or other dev boxes are not yet on 8.x then perform the same steps of redeploying new ones for the.

       

      With 8.x version in your kitty, you would no longer need an upgrade as this version allows only customization by extension hence setting up for faster uptake of new upcoming features

       

      Once your production environment is 8.x you would should expect a tile appearing on your project page on LCS about 10.x related action. You may choose to do this update as soon as it available or in consultation with your solution advisor.

From 8.x onwards, as I mentioned, it’s going to be only update (similar to applying platform updates)

Some brief steps are:

1)      Import the 10.0 version update in your LCS asset library.

  • Go to one of your non-production environment and apply the 10.0 update.
  • Validate and then apply the same in all other environment with production being the last one.

Volla!! – You can now retire the word upgrade from your IT landscape.