Dynamics 365

FastTrack Tech Talk

AX2012 to Finance and

Operations Apps Upgrade

Ankur Srivastava

Mo Alawa

About this Tech Talk

Objectives of this Tech Talk

Understand the end to end process for upgrading from AX 2012 to

Finance and operations apps including:

• Upgrade overview

• Code upgrade estimation and execution

• Data upgrade execution

• Key upgrade considerations and best practices

• Validation

What it doesn’t cover

• D365 Commerce / Retail SDK upgrade

• Data migration approach from AX 2009 / AX 2012

• Extensibility patterns deep dive

Contents

Source system preparation task5

2

Data upgrade preparation (source system)3

Execute4

Availability & Upgrade overview1

Data upgrade troubleshooting steps6

Validate7

Special considerations8

Analyze

9 Resources

Availability & upgrade overview

Availability

▪ Upgrade customers from AX 2012 R2 and

R3 to Finance and Operations apps (10.0.x).

▪ Upgrade from Dynamics AX 2012 RTM isn’t

yet supported.

Tool: Upgrade tools are managed through

LCS.

Upgrade overview

Code upgrade and Data upgrade

ValidateAnalyze

• Fit/Gap analysis

• Estimate code and

data upgrade/

migration tasks

• Create project plan

• Code upgrade

• AX 2012 database

preparation (pre-upgrade

checklist)

• Data upgrade

• Upgrade validation

• Functional test pass

• Cutover testing

• Go-Live

Execute

Source system – AX 2012Target system – Finance

and Operations apps

Analyze

Analyze Process

AX2012 Upgrade Overview

Run the

upgrade

analyzer

Sign up for

LCS

Select the

upgrade

methodology

Create

project plan

Run the Code

upgrade toolFit/Gap

analysis

Analyze – Sign up for LCS

Sign up for a Lifecycle Services trial or partner project

https://lcs.dynamics.com

To perform Analyze activities before you purchase

Finance and Operations, you need to sign up for a

Microsoft Dynamics Lifecycle Services (LCS) trial or

partner project. This lets you deploy your own

Finance and Operations environments. It also gives

you access to the tools in LCS that are used to

evaluate your AX 2012 environment and your

existing custom code.

If you have an existing LCS project for AX 2012, you

must still sign up for an additional LCS project for

Finance and Operations.

Select the upgrade methodology

In your new LCS project, set the project methodology

to Upgrade AX 2012 to Finance and Operations apps

This methodology is made specially for AX 2012

customers who are upgrading

It describes the three phases in detail and provides

links to all the supporting documentation about

the process

Analyze – LCS Project Methodology

Upgrade AX 2012 to Finance and Operations apps

Analyze – LCS Project Methodology in Implementation project

Run the upgrade analyzer

Upgrade Analyzer – AX 2012 pre-prod environment

Against AX2012 Pre-Prod environment

Identifies potential maintenance activities and deprecated features

Gathers data from your AX 2012 environment as part of the regular System diagnostic

service in Microsoft Dynamics Lifecycle Services (LCS).

Upgrade Analyzer Tool Enable strong cryptography

In case of connectivity issues between your AX 2012 environment and LCS, make sure

to verify if strong cryptography is enabled on your AOS machines.

You can view the results of the System diagnostic service in a Microsoft

Power BI report in LCS

To access the Upgrade analyzer report, go to

https://diag.lcs.dynamics.com/UpgradeAnalysisReport/Report/"ProjectID“

Upgrade Analyzer Report

(Replace "ProjectID" with your current project ID, which is an integer that can be found in the URL of your current LCS project).

Upgrade Analyzer Report

Upgrade analysis report Upgrade analysis

Analyze – code upgrade

LCS Service

Service that upgrades code to Finance and Operations apps.

Produces Excel Reports

Use it to estimate code upgrade effort.

Converts code and resolves most issues automatically with respect to over layering.

Run the Code upgrade tool

Analyze – code upgrade

Run the Code upgrade tool – continue….

Sign up for DevOps

Create code upgrade job, “Estimation Only”

Configure code upgrade in LCS

Run “Analyze code”

Upload model store to LCS

Review the report

Analyze code upgrade Configure for code upgrade

Analyze – Migration summary report

In analysis phase, use it to estimate

effort – Still not released yet.

Code analysis summary, including

customization information and remaining

over-layering details.

Analyze – code upgrade

Service which upgrades

code to D365 format

During run if “Estimation Only” is unmarked then

overlayered upgraded code will be

checked-in to DevOps.

Excel report

generated

Code checked into

DevOps

LCS codeupgrade service

Convert

to <XML>

Convert to

overlayering

Merge and

model split

Run auto

migration rules

Output

summary

Automatically Check-in

to DevOps

Deploy VM

via LCS

Map DevOps

to VM

Overlayering to

extension conversion

What does code upgrade tool do?

AX model upgrade overview

Run the Code upgrade tool

Analyze – code upgradeRun the Code upgrade tool – continue….

Verify overlayered upgraded code into DevOps

This is work in progress and will be made available soon. Until that’s released, reach out to Dynamics

365 Migration Programme to get similar assessment done.

In analysis phase we use it to estimate effort (Bucketing concept)

Bucket Type Definition

Small Extension is possible

MediumCan be converted to extensions – traversal is required

If needed, raise extension request

Large All report elements are defined as Large

Not in scope Extension is not possible – traversal is required

TBD Undefined – need to define the bucket size

Analyze – code upgrade

Extensibility request:

Run the Code upgrade tool – continue….

Why extension request are needed?

• Finance and Operations applications exclusively use extensions to customize the product.

• You will discover that some customizations, which were possible with over-layering,

cannot be done through extensions.

• To enable the same business requirements without over-layering, we have added many

extension capabilities and expect to add more going forward.

• If you encounter situation when extension is not possible, you will need to log extension

requests from LCS.

• As a pre-requisite to raising your extension request, make sure to go through the

extension tips blog post. In case you skip this part, your extension requests might be

rejected. You can find more details on FAQ.

Extensibility Requests Tips for logging extensibility requests Extensibility FAQ

Analyze – code upgrade

If you have 3rd party solutions/ISV solutions:

Run the Code upgrade tool – continue….

Ignore the code upgrade output for them

Contact the 3rd party for newer version for Finance and Operations apps.

Analyze – Fit/GapFit/Gap analysis

Use LCS to deploy sandbox environments of Finance and Operations apps.

In LCS preview project: Deploy a demo environment in your own subscription after

setting up a Microsoft Azure connector.

In LCS customer implementation project: Simply deploy

Perform Fit/Gap analysis, especially around new and deprecated features

Deploy demo environment for analysis

Analyze the data – Upgrade v/s Migrate

Upgrade

Data upgrade tool

Upgrade complete data

Use data management framework

Migrate reference, master and document data from legacy or external systems.

Migration

Analyze - Data upgrade preparation (source system)

2

Virtual company3

Data partitions4

Collation1

Database and file share storage for attachments

Data upgrade preparation (source system)

Collation

• AX 2012 supported various database collations

- Checking collation on AXDB: SELECT name, collation_name FROM sys.databases

- If collation doesn’t match SQL_Latin1_General_CP1_CI_AS , you must go through this process to change it.

• Finance and Operation apps support a single database collation (SQL_Latin1_General_CP1_CI_AS)

• Changing database collation (Full details published on Yammer)

- Import the bak file into the D365 dev env

- Export SQL Database (bak format) to bacpac format.

- Make a copy of the .bacpac file, rename it to .zip and then unzip it.

- Edit the Model.xml file.

- Change all Collation values to SQL_Latin1_General_CP1_CI_AS. Update CollationLcid to “1033”.

- Import SQL Database using the modified model.xml file

Database and file share storage for attachments

• AX 2012 offered either database or file shares storage for attachments

• Finance and Operation apps offers blob storage for attachments as a replacement

- Files share storage is no longer supported because cloud-hosted environments cannot communicate with local file shares.

- Database storage has been deprecated in favor of Azure Blob storage.

• Moving attachments to blob storage

- Move document files from on-prem shared location to database by running a script at source. Here is the GitHub link to

get script.

- Post upgrade use migrate option as documented here.

Virtual company• AX 2012 offered virtual company feature to share tables with set of companies

• Finance and Operations apps offers cross company data sharing as an alternative feature

- Virtual companies feature is no longer supported

- Switching tables from company specific to global or vice versa (i.e. Save Data Per Company property) is not allowed through

extensions

• Cross-company data sharing (More details can be found on docs article)

- Cross-company data sharing lets you replicate (share) reference and group data among companies

- Doesn’t offer full parity with virtual company feature

- Documented limitations needs to be considered during design, including data / table groups allowed, maximum allowed

volumes and number of shared companies

- Data upgrade tip: If data was previously shared in virtual company (or table made global), data should be moved to one

company during post sync and cross-company data sharing should be used – More details available in Appendix

Data partitions

• AX 2012 introduced Data partitions starting with R2 to enable data isolation.

• Finance and Operations apps uses database as the isolation container

• Data partitions replacement

- Customers using data partitions must use multiple instances of Finance and Operations if database level separation is a

critical issue.

Analyze – project plan

Project plan template provided in

LCS methodology.

Create project plan

Migration summary + Bucketing – Estimate

extension conversion based on samples

Upgrade analyzer – estimate AX 2012

preparation effort

Sandbox environment – First Fit-Gap

analysis – new customizations may be

needed

Use output from

Execute

Execute

Source system –

AX 2012

Run

pre-upgrade

checklist on

source system

Code upgrade

Source system

preparation tasks Data upgrade

Export

and import

database to

target system

Target system – Finance

and Operations apps

Execute – Switch to the LCS implementation project

The public preview project that you used for the Analyze phase has served its purpose. You can now discard it. For the remaining steps, you require only the project plan that you created in the final step of the Analyze phase.

When you purchase a subscription, you will receive details about how to sign

up for a new LCS project. This project is known as an implementation project

and will be the new permanent LCS project for your subscription, for as long

as you have that subscription. This project differs from the public preview

project in that it's managed by Microsoft. Therefore, this project has these

characteristics –

- All environments in the project are hosted in Azure.

- The Azure subscription that is associated with the project is managed by

Microsoft. Therefore, there is no separate billing for Azure costs. The

costs are covered by your subscription.

- The production environment in the project is maintained by Microsoft.

Therefore, code deployments, upgrades, and infrastructure maintenance

are run directly by Microsoft, not by customer \ partner staff.

LCS Project onboarding

Upgrade AX 2012 to Finance and Operations apps

When you first sign in to your LCS implementation

project, you're guided through the Project

Onboarding wizard. You can always visit the Project

Onboarding wizard later using the navigation menu next

to Project Settings in your project.

While on the Project Onboarding wizard, in the Project

Scope section, you can use the Legacy System field to

identify the project as an AX 2012 upgrade. It's crucial

that you identify the project in this way, so that the

sandbox infrastructure that is deployed is compatible

with the upgrade process that is outlined here. If this

step isn't completed early in the project, you might

accidentally deploy your Sandbox on a newer

infrastructure that is incompatible with this process. In

that case, the upgrade effort might be delayed.

Execute – code upgrade

Complete the tasks that were planned during the code upgrade estimation step of the

Analyze phase.

From this point onward, code changes in AX 2012 should be frozen. Only emergency code

changes should be allowed in AX 2012. If a change is made, it must be ported manually to

the new code base.

Owner of the intellectual property (IP) should own the DevOps account.

During code upgrade consider proper branching in Devops related to dev\Main\Release.

Draft and always follow naming convention during converting code from overlayering to

extension.

Code upgrade

Get new versions of ISV solutions

Refactor customizations (over-layering) to Extensions

• Start with platform model, then foundation and continue upwards because they reference each other

• Start with database schema objects (EDT, Enums, Tables, View) then move to other sets of objects (Class,

Forms, Query, Menu Items, Menus, Reports). Most importantly, start working on the data upgrade as

early as possible by separating database schema related things in the code upgrade from the rest and

start working on data upgrade in parallel.

• While working on each object during converting them to extension, complete it fully.

• While converting objects to extension, based on complexity of changes either customer can use F&O

Compare tool, or they can use AX 2012 compare tool to identify their customizations.

Redesign deprecated features (AIF & Integration \ Analytics \ Enterprise portal etc…)

Complete code upgrade and compile your extension package.

Do not use Visual Studio to create deployable packages.

Push your latest compiled code to a clean branch and configure DevOps build pipelines

against the clean branch to produce all-in-one deployable packages.

Find out more in this docs article.

Code upgrade – data upgrade script

There are 2 kinds of data upgrade

scripts

In general, we need to write an Upgrade Script when:

Schema ChangeHow to write upgrade scripts

for these changes

New unique index added New unique indexes

Enum Value change Enum values changed

Table/Field deleted Deleting a Table/Field

A new feature is added that requires data to be populated

so that the feature can be used

In case there is corrupted data and needs to be cleaned up

Major Version Data Upgrade scripts

(AX 2012 – D365 v10.0.x)

Minor Version Data Upgrade scripts

(AX7X – D365 v10.0.x)

A breaking schema change is introduced

Appendix (Page 60-64)

Execute – Source system preparation task

Execute – Perform the AX 2012 preparation tasks

• Complete the tasks that the upgrade analyzer tool discovered on source system and that

were documented in your upgrade project plan

• Collation – this activity can be done during importing bacpac database on target system

as explained in analyze phase.

• Use the pre-upgrade checklist to enter data that will be required for the upgrade

procedure.

Execute – Pre data upgrade checklist

• If upgrading from AX 2012 R3, install KB 4035163

• If upgrading from AX 2012 R2, install KB 4048614

• Validate baseline version

• Prepare model metadata

• Prepare security role metadata

• Set up user mapping

• Archive retail salt data

Run and execute all pre-upgrade checklist steps

Install a hotfix in AX2012 (pre-upgrade checklist)

Data upgrade deployable package

Tool: Data upgrade deployable package is

managed through LCS.

• Sign in to LCS.

• Select the Shared asset library tile.

• In the Shared asset library, under Select asset type,

select Software deployable package.

• In the list of deployable package files, find the data

upgrade package that corresponds to your upgrade.

- If you're upgrading from AX 2012, the package name

starts with AX2012DataUpgrade. Select the package

that corresponds to the release you are upgrading to.

For example, AX2012DataUpgrade-10-0.

• Select the package that corresponds to the release that

you are upgrading to.

• After you download the zip file, right-click it, and then

select Properties. Then, in the Properties dialog box, on

the General tab, select Unblock to unlock the files.

Data upgrade deployable package

• Data upgrade deployable package consist

- AXUpdateInstaller

- Runbook

• If you are upgrading a database on a development \ sandbox environment, you can instead execute the data upgrade

package directly from the LCS environment page, using the Maintain > Apply Updates servicing functionality. This

option was not available for sandbox environment earlier but recently it has been incorporated.

• Prefer way is to execute the package manually from the command line via Remote Desktop on the AOS Development

VM.

https://docs.microsoft.com/en-us/dynamics365-release-plan/2019wave2/finance-operations-crossapp-

capabilities/apply-data-upgrade-packages-ax-2012-customers-sandbox-environments#feature-details

Execute deployable packages from the command line (open Command Prompt window as an

administrator)

• Collect topology configuration data

- Extract the files

- In the folder where you extracted the deployable package, find and open the file that is named DefaultTopologyData.xml.

You must specify the VM name and the installed components in this file.

- Go to the extracted folder and run the following command to see a list of all the components that are installed on the

computer. Execute AXUpdateInstaller.exe list and get list of components.

- Update the DefaultTopologyData.xml file with the list of components.

• Generate a runbook from the topology

- AXUpdateInstaller.exe generate -runbookid=[runbookID] -topologyfile=[topologyFile] -

servicemodelfile=[serviceModelFile] -runbookfile=[runbookFile]

• Import the runbook

- AXUpdateInstaller.exe import -runbookfile=[runbookFile]

• Execute the runbook

- AXUpdateInstaller.exe execute -runbookid=[runbookID]

https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/deployment/install-deployable-

package#generate-a-runbook-from-the-topology

What does data upgrade package do?

Data upgrade package has various steps which includes pre-req, pre-sync, database sync, post-sync, final database sync, stopping and starting various services and many more.

Pre-req• Preparing source database for upgrade process

Pre-Sync and Post-Sync• A lot of new changes happened in metadata from AX 2012 to v10.x as part of standard changes.

• Changes could be anything (Made a field obsolete, bring a unique index on table, populating default values to any new config

tables, any Enum element change etc.), so in these cases we need scripts in place to handle these specific changes. These scripts

are part of standard package and you can find same in application as (ReleaseUpdateDB* classes).

• These scripts run as part of pre-sync and post-sync steps.

Database sync and final database sync• Database Sync is the process of synchronizing the AX metadata (tables, views, entities) of v10.x version into the SQL database of

AX 2012 version. It uses some internal tables (SqlDictionary) in the database to track the state of the metadata as persisted in

the DB and compares it with the new metadata that is being deployed. When changes are detected, modifications are made to

the Sql in order to bring the DB in sync with the metadata.

Execute - Data upgrade troubleshooting steps

Troubleshooting data upgrade script errors while executing runbook manually

• Rerun the runbook after a data upgrade script failure

- AXUpdateInstaller.exe execute -runbookid=[runbookID] -rerunstep=[stepID]

- When you're debugging, you don't have to rerun the whole data upgrade piece and database synchronization. You can keep

rerunning just the script that fails.

• View more details about a script error

- Upgrade scripts run in X++ by using a batch process that the runbook installer starts. In Application Explorer in Visual Studio,

some classes that you can view are prefixed with ReleaseUpdate. If an upgrade script fails during the runbook process, you

can learn more about the reason for the error by opening Microsoft SQL Server Management Studio and running the

following code to query ReleaseUpdateScriptsErrorLog.

- select * from RELEASEUPDATESCRIPTSERRORLOG

• Skip failed scripts –

- This process is intended to be used only in a development scenario.

- You can skip all scripts that have failed a specific number of times and move to the next viable scripts. This functionality helps

with the troubleshooting process. By design, the process is very manual, so that you're less likely to unintentionally skip

scripts.

Troubleshooting data upgrade script errors while executing runbook manually

• Monitor the duration of scripts that are run

- Every script that is successfully run records the number of minutes that it took in

the ReleaseUpdateScriptsLog.DurationMins column. Therefore, you can easily identify the longest-

running scripts when you're trying to tune the performance of the data upgrade process. Note that

the duration is the amount of time that each script takes to run. However, because multiple scripts run

in parallel, the sum of values in the DurationMins column will exceed the overall duration of the

upgrade process.

• Event viewer – to track progress and failure

- Event Viewer > Applications and Services Logs > Microsoft > Dynamics > AX-DataUpgrade

Pre-Sync and Post-Sync script details are logged in this section of event viewer.

- Event Viewer > Applications and Services Logs > Microsoft > Dynamics > AX-DatabaseSynchronize

Database sync and final database sync details are logged in this section of event viewer.

Data upgrade development \ sandbox environment

Data upgrade on development environment Data upgrade on sandbox environment

• It provides local data that developers can write and test their

custom data upgrade scripts against.

• It helps reduce the overall time that is spent on iterations of the

data upgrade process. In a development environment, an issue

can be debugged immediately, code can be adjusted, and the

upgrade can be rerun within minutes.

• Cloud hosted \ Development environment uses Microsoft SQL

Server.

• This process needs bak file to be import on cloud hosted \

development environment.

• Sandbox refers to a Standard or Premier Acceptance Testing

(Tier 2/3) or higher environment connected to a SQL Azure

database. On this environment business users and functional

team members can validate application functionality. This

functionality includes customizations and the data that was

brought forward from Microsoft Dynamics AX 2012.

• A sandbox environment uses Microsoft Azure SQL Database for

data storage.

• This process needs bacpac file to be import on sandbox

environment.

Data upgrade in development environments

Target as cloud hosted environment

Target as cloud hosted environment

• Back up your AX 2012 database as bak file format

• Upload the backup to Azure Storage

• Download and restore the backup to the development environment (cloud-hosted

environment)

• Run the data upgrade deployable package

- Execute the package manually

- Execute the package through LCS

• Cloud hosted \ Development

environment uses Microsoft SQL

Server.

• This process needs bak file to be

import on cloud hosted \

development environment.

Data upgrade in sandbox environments

Target as sandbox environment

Target as sandbox environment • Turn off the AX 2012 AOS instances

• Create a copy of the AX 2012 database

• Run the T-SQL script to prepare the database

- This is important if your AX 2012 R2 or R3 application was upgraded from AX 2012 RTM.

- This script prepares the database by removing users, removing procedures related to the

AX 2012 RTM model store, cleaning up schemas, dropping views, and dropping

references to tempDB

• Export the copied database to a bacpac file by using a SQLPackage.exe tool

• Upload the bacpac file to Azure storage or the LCS Asset Library

• Import the bacpac file into SQL Database

• Run the following script against the imported database. The script performs following actions

- Recreates database users

- Sets the correct performance parameters

- Enables the SQL Query Store feature

• Run the appropriate data upgrade package against the imported database through LCS

• A sandbox environment uses

Microsoft Azure SQL Database for

data storage.

• This process needs bacpac file to be

import on sandbox environment.

Validate

Data upgrade and application validation:

Smoke test to answer these questions

Validate

Did all the services start?

Are all application components accessible?

Number of records in important tables?

Is the expected data there?

Does General Ledger reconcile to AX 2012?

Does Inventory reconcile to AX 2012?

Application functional validation

Data validation workspace

Validate

Final steps:

Perform cutover testing: Technical and functional

Complete functional testing (Functional test pass)

Smoke test to answer these questions (Prepare for Go-Live)

Create cutover plan

Project template available in methodology

Code freeze

Application configuration freeze

Final cutover test

Upgrade cut-over testing App validation process Upgrade functional validation Upgrade go-live prep

Go live

Start

Perform

smoke testEndAllow users

back in

Complete

application

setup

Downtime

Copy database

to production

Turn off AX2012

AOSes

Backup your

AX2012 DB &

run TSQL

against original

Export to

bacpac, upload

to AOS machine

Import

the bacpac

to sandbox

environment

Execute data

upgrade

2012 Upgrade Cutover

Special considerations

Special considerations

Transactional replication

• Transactional replication (For large database)

- Transactional replication is the automated periodic distribution of changes between databases. Data is copied in (or near)

real-time from the primary server (publisher) to the receiving database (subscriber). Thus, transactional replication offers an

excellent backup for frequent, daily databases changes.

• Cutover time

- Cutover testing (Mock cutover) - The purpose of upgrade cutover testing (mock cutover) is to practice the cutover process,

to help guarantee a smooth experience for everyone who is involved during the actual cutover to Go-Live.

- Cutover (Go-Live) - Cutover is the term that we use for the final process of getting a new system live. This cutover process

consists of the tasks that occur after Microsoft Dynamics AX 2012 is turned off but before Finance and Operations is turned

on. Before you plan your final cutover, you need to successfully complete one successful mock cutover as described

in Cutover testing.

• Upgrade timing

- Data upgrade timings on Tier-1 environment or Tier-2 environment(s) varies based on database to database level as every

database is unique and different from others. So if you trying to predict actual data upgrade during cutover planning then

possible prediction can be done once you successfully complete data upgrade on Tier-1 and Tier-2 environment based on

your volume. Also in actual production upgrade run take extra 20-30% buffer time what it took in Tier-2 environment.

Resources

AX2012 Upgrade Overview

Upgrade Analyzer Tool

System Diagnostics Services

Analyze code upgrade

Configure for code upgrade

Extensibility Requests

Deploy demo environment for analysis

Prepare to migration code

Configure VSO Solution

Extensibility

Target as cloud hosted environment

Target as sandbox environment

Data upgrade on development environment

Data upgrade on a sandbox (Tier2+)

environment

Data validation workspace

Upgrade cut-over testing

App validation process

Upgrade functional validation

Upgrade go-live prep

2012 Upgrade Cutover

Upgrade document management

Transactional replication

Partitions

Thank you.

Setting up the Script Class

• Create a new class – Name convention

- ReleaseUpdateDB<Release>_<CustomerPackageName>

• Ensure the class extends the ReleaseUpdateDB class

• Override the moduleName and myVersion methods

• Upgrade Scripts are composed of the following parts

- Upgrade Attributes - tell the upgrade framework how and when to schedule the script during the Upgrade Process.

- Upgrade Script body - does the actual data manipulation.

Appendix 38

Upgrade Script Attributes• Upgrade Stage - Major Version Upgrade Stages

- UpgradeScriptStageAttribute(ReleaseUpdateScriptStage::PreSync) - Tells the Upgrade framework to schedule the script

during the PreSync step of a Major Version Upgrade

- UpgradeScriptStageAttribute(ReleaseUpdateScriptStage::PostSync) - Tells the Upgrade framework to schedule the script

during the Post-Sync step of a Major Version Upgrade

• Script Type

- UpgradeScriptTypeAttribute(ReleaseUpdateScriptType::SharedScript) - Tells the Upgrade Framework to schedule the

script as a Shared Script. The script will run only once. Use this when the SaveDataPerCompany and SaveDataPerPartition

properties on the table being accessed by the script are both set to No

- UpgradeScriptTypeAttribute(ReleaseUpdateScriptType::StandardScript) - Tells the Upgrade Framework to schedule the

script as a Standard Script. The script will run once for each company (DataArea) in the System. Use this when the

SaveDataPerCompany property on the table being accessed by the script is set to Yes

- UpgradeScriptTypeAttribute(ReleaseUpdateScriptType::PartitionScript) - Tells the Upgrade Framework to schedule the

script as a Partition Script. The script will run once for each Partition in the System. Use this when the SaveDataPerPartition

property on the table being accessed by the script is set to Yes and the SaveDataPerCompany property is set to No

• Script Dependencies - In some instances, we need to ensure a script runs after another script. We

have the following attributes to deal with this:

- UpgradeDependsOnTaskAttribute: Used to specify dependencies between scripts within the same class

- UpgradeDependsOnModuleAttribute: Used to specify dependencies between scripts that live in different classes

- UpgradeDependsOnVersionAttribute: Used to specify dependencies between scripts that live in different classes and whose

myVersion() method returns different versions

Code upgrade – data upgrade script Example 1

PaymSchedLine – Compare to AX 2012, we added a unique index

“NameLineNumIdx” in F&O apps

- Added logic in PreSync to disable unique index

- Update PaymSchedLine table to include NameLineNumIdx{Name, LineNum} as

unique key during PostSync process

Code upgrade – data upgrade script Example 2

WHSContainerType – In AX 2012, as part of customization, customer changed table property

“SaveDataPerCompany” to “No”

- In Finance and Operations apps extension, we can not change table property “SaveDataPerCompany”. In database coming from AX

2012, due to customization there will be no dataareaId on table. But with respect to Finance and Operations apps during first

database synchronization in upgrade run dataareaId will be defaulted with ‘DAT’ company. So with PostSync process move data to

one company and then use cross-company data sharing

Code upgrade – data upgrade script Example 3

A new feature is added that requires data to be populated so that the feature can be used

- In F&O apps there is a new field (fileId) added to DocuValue table. We have a PostSync script for populating the FileId column with a

unique GUID on each row.

Appendix 38