Operational differences to consider
The following sections discuss operational differences between AX 2012 and finance and operations apps.
Lifecycle Services
Microsoft Dynamics Lifecycle Services helps improve the predictability and quality of implementations by simplifying and standardizing the implementation process. Lifecycle Services is a Microsoft Azure-based collaboration portal that provides a unifying, collaborative environment along with a set of regularly updated services that help you manage the application life cycle of your implementations.
Lifecycle Services is mandatory for finance and operations apps implementations.
The aim of Lifecycle Services is to provide the right information to the right people at the right time and to help ensure repeatable, predictable progress of an implementation, update, or upgrade. Lifecycle Services encourages closer communication, helps accelerate development, and reduces time by offering a shared workspace that can be used by consumers and partners, both independently and together.
When you have your subscription for finance and operations apps, you will start with onboarding to the service through Lifecycle Services. This process is like acquiring your installation media, license keys, and installation materials for AX 2012.
Next, you will deploy. You can rapidly deploy the application on Azure. It’s important to consider that finance and operations apps can be deployed to a subset of Azure regions. For more information, see Dynamics 365 and Microsoft Power Platform availability. In contrast to AX 2012, you don’t have to conduct hardware planning or complete installation steps.
Servicing is simplified, as is the ability to discover updates and bug fixes, by using Lifecycle Services. Compared to AX 2012, you no longer need to use manual steps for hotfix discovery and installation.
Finally, you can log support cases quickly and directly from your implementation project. You no longer need to sign in to a separate portal for support management as you did with AX 2012. For more information, see Get started with Lifecycle Services for finance and operations apps.
Environment management
Environments are managed in Lifecycle Services. Multiple processes are happening in your environments, such as development, regression testing, performance testing, code upgrade, and data migration. You also need to have your production environment where transactions are being processed. Except for tier one developer environments, these environments are managed by Microsoft. Because many parallel processes are occurring simultaneously in different environments, it’s important that you go through environment planning. You should consider how many development environments, test environments, and so on that you need.
Debugging has also changed. Debugging no longer occurs on a production environment because no source code exists in production (only binaries are deployed to production). Debugging is performed in the developer environment. Several tools are available to you for troubleshooting in Lifecycle Services or through database access.
Database access has also changed. You no longer have access to the production database. SQL Server Management Studio access is not available for the production database. You can debug data by creating a copy of the production data into a UAT environment, for example.
You need to be aware of several environment tiers, especially when you are going through environment planning. Each of the tiers has a different cost and purpose.
Tier-2 and higher environments
Tier-2 and higher environments are multi-box environments . These boxes use Azure SQL. The architecture is the same as the Production environment, though it doesn’t have high availability and disaster recovery like a production environment would have. Tier-2 and higher environments are managed by Microsoft, and they can’t be hosted by the customer or partner. Therefore, these environments are add-ons.
Standard subscription environments
Each finance and operations apps subscription comes with the following features:
- One production instance for each tenant. The production multi-box instance comes with disaster recovery and high availability.
- One Standard Acceptance Testing instance for the life of the tenant. Additional sandbox/staging instances can be purchased separately as an optional add-on. This non-production multi-box instance can be used for user acceptance testing, integration testing, and training.
For more information, see Dynamics 365 pricing.
Production environment
Production environments enable high availability and disaster recovery. Production environments are intended to be used for production processes and transactions. As a reminder, the production environment is fully managed by Microsoft, and access is not provided to the production database. To obtain a production environment, you must go through the Go-Live assessment, which ensures that the usage profile is up to date and activated in Lifecycle Services, that code and configuration is ready, and that the customer UAT is signed off. The production environment is released at the end of UAT (about one month before go-live).
When the production environment has been deployed, we recommend that you perform a practice cutover in production, including a final round of testing. Additionally, a point-in-time restore can be used to restore Production to a clean snapshot (which is taken every 15 minutes, for up to 30 days).
For more information, see Prepare to go-live with finance and operations apps.
Data management
The data management capabilities that are built into finance and operations apps enable you to set up data integrations, use the data import/export framework, migrate data, perform data refreshes, and work with your data entities. Data entities are denormalized views of your tables that enable you to use the data management capabilities. Data entities are similar to a view.
For more information, see Work with data management in finance and operations apps.
Continuous updates and One Version
Microsoft is continuously shipping updates to the Dynamics 365 application. The goal of One Version is that all organizations that are using Dynamics 365 are on the same version and are continuously updating the application. This approach has several benefits. One benefit is that you are always on the latest version of the application, which also saves time, money, and effort on future application or version upgrades. Continuous updates are handled by using Lifecycle Services, and application lifecycle management (ALM) should include the Microsoft updates. Continuous updates should also be considered when you are determining your environment strategy. You need to ensure that you have sufficient environments that you can release your customizations and code to and that can handle Microsoft updates.
For more information, see One Version service updates overview.
You can use automated testing by using the Regression suite automation tool (RSAT). This tool allows you to run automated testing when you are running updates.