Other Considerations

Review these additional considerations before you migrate your data to Education Cloud.

Technical debt: Run Salesforce Optimizer to identify potential issues, and address them. The common causes for issues are:
- Object automation across workflows, flows, and triggers.
- Custom object and custom field usage that leads to running against limits, or empty fields.
- Sharing models and sharing rules that affect legacy objects.
- Outdated installed packages.
Current customizations: Objects might behave differently based on how objects relate to person accounts. Review the information that relates to contact records and person account records.
Current integrations:
- Replicate primary integrations with considerations for source objects and contact profiles.
- Test integrations to ensure that records can be created and updated after account-contact pairs are converted to person accounts.
Table-Driven Trigger Management (TDTM):
- Avoid TDTM as it isn’t compatible with Education Cloud.
- Deactivate existing trigger handler records before you migrate your data to Education Cloud.
- Transform TDTM automations and remap them to Flow or Apex-based solutions by using trigger handler best practices. Use One Per Object designs to maximize efficiency and execution control.
- Consider these steps when you migrate your data from a managed package environment with TDTM:
  - Review which trigger handler records are active.
  - Review the automations that need to be migrated to Education Cloud.
  - Evaluate custom TDTM classes and trigger handler records for applicability or improvement.
Integration with Marketing Cloud:
- Migrate the subscriber keys if the person account ID in Education Cloud is different from the contact ID or lead ID in Marketing Cloud.
- Use a multi-org connector to migrate to a new org.
- Reimplement Marketing Cloud Connect for new objects and triggers if required.
- Consider that the Marketing Insights for Sales Cloud App dashboard might not work.
Storage limits: When migrating data, the data is copied and not moved. As a result, your org’s data storage will reflect both your original data and copied data that is created by the migration kit. Expect data bloating for frequently used objects during the migration.