FieldOne Sky to Dynamics 365 for Field Service Migration Guide

The FieldOne Sky to Field Service for Dynamics 365 migration effort should be planned out as you would any Dynamics CRM add-on or Dynamics CRM enhancement project. Even with the use of the migration tooling this will be a significant manual effort.

This guide is inteneded to help you plan for a FieldOne Sky to Field Service for Dynamics 365 migration as well as covering the important aspects of the migration. A Microsoft Project file is available to help you plan the timeline and effort for your migration project.

Planning

Test Cases

Be sure you document test cases for all of your business scenarios. Ensuring that you perform adequate testing of the Field Service for Dynamics 365 solution as part of the migration effort is critical. While the Field Service solution is based on the legacy FieldOne Sky solution there are some functional changes that you need to ensure are getting tested properly. See Apendix A for an overview of the important functional changes.

Integrations

As part of the migration you will need to update any integrations you have to work with the new schema. When planning your Field Service migration identify who will be the key stakeholder for the integrations. This individual will need to manage the updates and testing of the integrations.

Portals & External Applications

If you are using ADX Studios for your portal you will need ensure that the necessary updates are made to have your portal implementation work with Field Service for Dynamics 365. This document does not cover what changes are required to ensure ADX Studios portal will work with Dynamics 365 and Field Service for Dynamics 365.

Custom portals and external applications will need to be updated to work with the new Field Service for Dynamics 365 schema.

As with your integration(s) you should identify a key stakeholder for your portal and external applications. This key stakeholder will need to manage the updates and testing.

Customization / Code Freeze

One the Field Service migration effort is started all customization and code changes must be stopped until the Field Service migration is completed.

Source Environment Preperation

The following section covers what steps should be taken to have your current production and development environments ready for a Field Service migration. This document assumes you have a development CRM environment and a production CRM environment. You may have additional environments however; this document will cover the preparation steps for the development and production CRM environments.

One important consideration. The schema (Entities, Attributes, Option Sets, Workflows, etc.) must be an exact match between your development and production environments.

Source Development Environment

Your current development CRM environment will be used by the migration tooling to parse your existing customizations and migrate them to the target org.

You should ensure that all customizations in your development CRM environment exist in your production CRM environment as well. If you have customizations in the development CRM environment that are not in the production CRM environment it is recommend that you delete the customizations or deploy them to your production CRM environment. The schema must be an exact match between your development CRM environment and production CRM environment.

Entity Form Security Cleanup

If you have entities where a form for the entity is configured to be available to specific security roles you will need to update the forms to be displayed to everyone.

After you complete the parsing and migration of the solutions defined in section 2.1.2 you can reconfigure the form-based security.

Migration Solutions

It is recommended that you create the following solutions in your development CRM environment. This will make the parsing and migrating of your customizations via the migration tooling much more streamlined and easier to manage.

  • 1-F12FS Migration – Web Resources
    • All custom web resources
    • This solution will NOT be parsed by the migration tooling.
    • Create this solution so there is a backup of the Web Resources that may require manual updates.
    • While this solution is not parsed by the tooling it will be necessary to import this solution to the target CRM environments first if there are entity forms that have a dependency on a web resource contained in this solution.
  • 2-F12FS Migration – Entities
    • All custom entites (including all assets for each entity)
    • All FieldOne Sky out-of-box entities that have been modified (including all assets for each entity)
    • All core CRM entitie that have been modified (including all assets for each entity)
    • All cutom global option sets
    • Client Extensions – Application Ribbons and Site Map

    If you have entities using forms where the form is configured to be displayed to specific security roles. You could export this solution as a backup. Then modify all forms for all entities to be displayed to everyone. After you successfully parse this solution and import it to your target environment you can the re-import the copy of this solution to restore the from configurations.

  • 3-F12FS Migration – Templates
    • All custom Article Templates
    • All custom Contract Templates
    • All custom Email Templates
    • All custom Mail Merge Templates
  • 4-F12FS Migration – Processes
    • All custom Workflows
    • All custom Business Process Flows
  • 5-F12FS Migration – Dashboards
    • All custom Dashboards
  • 6-F12FS Migration – Security
    • All custom Security Roles
    • All custom Field Security Profiles
  • F1FS Migration – Plugins
    • All custom plugins and plugin steps.
    • This solution will NOT be parsed by the migration tooling.
    • Create this solution so there is a backup of the plugins and plugin steps that require manual updates.

The number at the start of each solution name above identifies the order they should be parsed by the tooling and imported to the target environment.

Source Code

Ensure that source code for all custom plugins is available. This source code will need to be updated during the Field Service migration.

Source code for custom web resources such as JavaScript and HTML can be exported from the current development CRM environment.

Source Production Environment

For the current production CRM environment, it is critical that all customizations match the customizations in the development CRM environment. You will need to validate that customizations have not been made directly in the production CRM environment which are not in the development CRM environment.

Target Environment Preperation

The target environments will be upgraded to CRM 8.2 and Field Service 6.2. During the migration process there will be a minimum of two target CRM environments created. To complete the Field Service migration two available Sandbox instances will be required. Please contact support or your Microsoft account team if you require additional Sandbox instances for the tenant.

FS Migration PreProd

The first target environment to create will be the new production CRM environment.

  1. Backup current production CRM environment.
  2. Restore production backup to a new Sandbox instance.
    1. This new Sandbox instance should be named fsmigration-preprod
  3. Upgrade fsmigration-preprod to CRM version 8.2.x
    1. It may be necessary to open a support ticket to have the PreProd CRM environment upgraded to CRM version 8.2.x
  4. Using the tooling remove the FieldOne Sky solution
  5. Using the tooling import the Field Service solution version 6.0
    1. Do NOT install Field Service version 6.2.x at this time.
  6. Use the Field Service Migration Tooling to parse and import the solutions defined in section 2.1.2 of this guide. See the Field Service Migration Tooling documentation for details related to parsing and migration custom solutions.
    1. Use the Field Service Migration Tooling to synchronize data from the current production CRM environment to the fsmigration-preprod CRM environment.
    2. Refer to the FS Migration PreProd – Initial Data Synchronization #1 section in this document.
  7. Create the FS Migration Dev environment.
    1. Use the Field Service Migration Tooling to perform daily data scnchronization runs from current production CRM environment to the fsmigration-preprod CRM environment.
    2. Refer to the FS Migration PreProd – Daily Data Synchronization section in this document.

FS Migration Dev

Once the fsmigration-preprod is ready a backup of fsmigration-prod will be made to create the FS Migration Development environment.

  1. Backup fsmigration-preprod CRM environment
  2. Restore fsmigration-preprd backup to a new Sandbox instance.
    1. This new Sandbox instance should be named fsmigration-dev
    1. Use the Field Service Migration Tooling to synchronize data from the current production CRM environment to the fsmigration-dev CRM environment.
    2. Refer to the FS Migration Dev – Synchronization #1 section in this document
  3. Upgrade the Field Service solution via the Dynamics 365 Administration Center.
    1. Prior to performing the Field Service solution upgrade via the Dynamics 365 Administration Center the following steps must be performed.
      1. All Field Service entities must have the following options turned off (unchecked). To be safe it is recommended to turn these options off for all entities and then turn the options back on after the Field Service solution upgrade is completed.
        1. Enable for mobile
        2. Offline capability for Dynamics 365 for Outlook
      2. All Fied Service out-of-box plugin steps and processes MUST be enabled.
  4. Use the Field Service Migration tooling to disable all plugin setps and processes.
    1. Use the Field Service Migration Tooling to synchronize data from the current production CRM environment to the fsmigration-dev CRM environment.
    2. Refer to the FS Migration Dev – Synchronization #2 section in this document.
  5. Use the Field Service Migration tooling to enable the plugin steps and processes that were disabled in step 5 above.

At this point the fsmigration-dev CRM environment can be used to update code-based customizations such as custom plugins and JavaScript web resources.

FS Migration UAT

If desired a UAT CRM environment can be created. To create a UAT CRM environment backup the fsmigration-dev CRM environment and restore this backup to a new Sandbox instance.

  1. Backup fsmigratoin-dev CRM environment
  2. Restore fsmigration-dev backup to new Sandbox instance.
    1. This new Sandbox instance should be named fsmigration-uat

As the manual updates to customizations are made in fsmigration-dev they should be exported from fsmigration-dev as managed solutions and imported to fsmigration-uat.

The Field Service Migration Tooling will NOT be used to synchronize data to the fsmigration-uat CRM environment.

Manual Updates

The are multiple components that will require manual updates. The primary updates required are related to the schema changes between FieldOne Sky and Field Service such as f1_workorder changing to msdyn_workorder. Review the Excel file for details on the schema mapping.

Thre are some functional changes that may require updates to the customizmations created for FieldOne Sky. See Appendix A of this document for details on functional changes that may impact your current implementation.

During the time needed to update customizations it is recommended to perform daily data synchronization between the current production CRM environment and the fsmigration-preprod environment. Refer to section 5 of this document for details.

Custom Plugin(s)

All custom plugins that rely on FieldOne Sky entities will need to be updated to work with the Field Servcie schema. Using the fsmigration-dev make the needed updates to the custom plugins.

Create a solution in the fsmigration-dev environment that contains all custom plugin and plugin steps. This solution will be used to migrate the custom plugins to the fsmigration-preprod environment.

Custom Web Resources

All custom JavaScript and HTML web resources that rely on FieldOne Sky entities will need to be updated to work with the Field Service schema. Using the fsmigration-dev CRM environment make the needed updates to the custom web resources

Create a custom solution in the fsmigration-dev CRM environment that contains all custom web resources. This solution will be used to migrate the custom web resources to the fsmigration-preprod CRM environment.

Data Synchronization

The data synchronization is not done in a single pass. During the Field Service migration effort multiple data synchronization runs will be performed using the Field Service Migration tooling.

The following details important considerations related to the datamigration for each of the target environments.

FS Migration PreProd

The fsmigration-preprod org will requires two data synchronization runs as part of the initial data synchronization. After the initial data synchronization is completed continuous daily data synchronizations should be performed during the Field Service migration effort.

FS Migration PreProd – Initial Data Synchronization

For the first initial data synchronization run all entities will be synchronized by the Field Service migration tooling excluding the following entities.

  • f1_workorder
  • f1_workorder child records
  • f1_workorderresource
  • f1_workorderresource child records
  • f1_agreementinvoicedate
  • f1_agreementscheduledate
  • Entities flagged as "never scynchronize"
    • See the Data Synchronization Section in this guide.

The above listed entities will be synchronized during the production go-live step.

FS Migration PreProd – Daily Data Scynchronization

After completing the initial data synchronization to fsmigration-preprod a daily data synchronization should be performed. Use the Field Service Migration Tooling option "Migrate modified records on or after specified date" to synchronize data modified since the last daily data synchronization run.

Exclude the following entities during the daily data synchronization runs.

  • f1_workorder
  • f1_workorder child records
  • f1_workorderresource
  • f1_workorderresource child records
  • f1_agreementinvoicedate
  • f1_agreementscheduledate
  • Entities flagged as "never scynchronize"
    • See the Data Synchronization Section in this guide.

The above listed entities will be synchronized during the production go-live step.

FS Migration Development

For the fsmigration-dev CRM environment there are two data synchronization steps. First synchronization step is prior to installing the latest Field Service solution and the second synchronization step is after the Field Service solution is upgraded to version 6.2.x.

FS Migration Dev – Synchronization #1

Prior to upgrading the Field Service solution to the latest version data for the entities that are not synchronized to fsmigration-preprod can be synchronized to fsmigration-dev. Again, this data will still be a subset of the data in the current production environment.

Work Orders that are unscheduled, scheduled or in-progress need to be synchronized to the fsmigration-dev CRM environment before installing the latest Field Service solution.

As part of the Field Service solution upgrade there are post processing scripts which create records needed to support the new features added to Field Service version 6.2.x. For the post upgrade scripts to complete in a timely manner the number of work orders, work order child records and work order schedules needs to be minimized.

When synchronizing data to the fsmigration-dev CRM environment prior to the Field Service solution upgrade synchronize all entities excluding those entities that should never be synchronized.

For the following entities use a FetchXML query to limit the data being synchronized:

  1. f1_workorder
    1. Use a FetchXML query to synchronize only work orders with the following statuses
      1. Open – Unscheduled
      2. Open – Scheduled
      3. Open – In Progress
  2. f1_workorder child records
    1. No FetchXML is needed here. The only child records that will successfully sync are those records where the parent work order was synchronized. If desired, you could create a FetchXML query for each child entity to only synchronize records where the parent work order has one of the following statuses.
      1. Open – Unscheduled
      2. Open – Scheduled
      3. Open – In Progress
  3. f1_workorderresource
    1. Use a FetchXML query to synchronize only work order schedules where the parent work order has one of the following statuses
      1. Open – Unscheduled
      2. Open – Scheduled
      3. Open – In Progress
  4. f1_workorderresource child records
    1. No FetchXML is needed here. The only child records that will successfully sync are those records where the parent work order schedule was synchronized. If desired, you could create a FetchXML query for each child entity to only synchronize records where the work order for the work order schedule has one of the following statuses.
      1. Open – Unscheduled
      2. Open – Scheduled
      3. Open – In Progress

Exclude the following entities as well as those entities that should never be migrated.

  1. f1_agreementscheduledate
  2. f1_agreementinvoicedate

FS Migration Dev – Synchronization #2

After the Field Service solution has been upgraded to 6.2.x the work orders and related records that were not synchronized as part of FS Migration Dev – Synchronization #1 can be synchronized.

Use the Field Service Migration Tooling to disable all plugin steps and processes.

Use the Field Service Migration Tooling to synchronize all entities excluding the entities that are part of the "Never Synchronize" list.

For the following entities use a FetchXML query to limit the data being synchronized:

  1. f1_workorder
    1. Use a FetchXML query to synchronize only work orders with the following statuses
      1. Open – Completed
      2. Closed – Posted
      3. Closed – Canceled
  2. f1_workorder child records
    1. No FetchXML is needed here. The only child records that will successfully sync are those records where the parent work order was synchronized. If desired, you could create a FetchXML query for each child entity to only synchronize records where the parent work order has one of the following statuses.
      1. Open – Completed
      2. Closed – Posted
      3. Closed – Canceled
  3. f1_workorderresource
    1. Use a FetchXML query to synchronize only work order schedules where the parent work order has one of the following statuses
      1. Open – Completed
      2. Closed – Posted
      3. Closed – Canceled
  4. f1_workorderresource child records
    1. No FetchXML is needed here. The only child records that will successfully sync are those records where the parent work order schedule was synchronized. If desired, you could create a FetchXML query for each child entity to only synchronize records where the work order for the work order schedule has one of the following statuses.
      1. Open – Completed
      2. Closed – Posted
      3. Closed – Canceled

Exclude the following entities as well as those entities that should never be migrated.

  1. f1_agreementscheduledate
  2. f1_agreementinvoicedate

After you complete FS Migration Dev – Synchronization #2 use the Field Service Migration Tooling to enable the plugin steps and processes that were disabled prior to running this data synchronization.

Entities Never Synchronized

The following entities should never be synchronized by the Field Service Migration tooling.

  • f1_fieldonesetting
  • f1_fieldonesystemjob
  • f1_poolwogeneration
  • f1_scheduleboardsettings
    • This entity defines the schedule board tabs. It is recommended that you re-create the needed schedule board tabs in Field Service.
  • f1_systemuserschedulesettings
    • This entity defines user specific settings for schedule board tabs. It is recommended that you re-create the needed schedule board tabs in Field Service.
  • processsession
    • All workflows system jobs in a waiting state will need to be manually restarted in the target environments as needed.

Production Go-Live

For the production go-live it should be expected to take approxemtly 30 hours to complete. During the production go-live the current production environment must not be used. You will be performing a final data synchronization during the production go-live. After the final data sync, it will not be possible to perform additional data synchronizations thus any changes in the original FieldOne Sky production environment after the final data sync will not be available in the fsmigration-preprod environment.

Please refer to the Microsoft Project file for a detailed list of steps that need to be performed during the production go-live phase.

Appendix A – Functionality Changes

There are some key functionality changes that will need to be accounted for during the Field Service migration. This section does not attempt to cover every functionality change rather those changes that typically impact existing customizations in a FieldOne Sky implementation.

There are several deprecated entities and attributes, please refer to the Excel file for schema changes to review what entities and attributes have been deprecated. Any FieldOne Sky attribute flagged as deprectated in the Excel file will NOT be migrated to the target environment(s) by the Field Service Migration Tooling.

Primary Resource Schedule

This FieldOne Sky attribute is deprecated. A custom data migration effort will be required to preserve this data if needed.

Preferred Resource

Field Service allows for multiple preferred resources. The Requirement Resource Preference entity is used to track preferred resources. This functionality was changed in Field Service 6.2. As such work orders that are migrated to the target environment prior to upgrading the Field Service solution from 6.0 to 6.2 a Resource Requirement Preference record will be created when the Field Service post upgrade scripts are run.

It is recommended to limit the work orders that are migrated to the target environment(s) prior to upgrading Field Service to version 6.2.

Followup Work Order

This functionality has been deprecated in Field Service. A custom solution and data migration process will be required to preserve this functionality.