Marketing Cloud Engagement | Considerations for Migrating MobilePush to a Different MID/EID

Key Migration Considerations

MCE does not provide a standard feature for migrating an application to a new environment. If migration is unavoidable, you must plan and test for various scenarios in advance, using this article as a reference.

Please note that these considerations are extensive, and the required actions will vary based on your application's requirements and specific situation. Therefore, Salesforce Support cannot provide comprehensive advice on your overall migration project.

1. Application Update is Required The MobilePush SDK requires configuration information, such as the Application ID, from the destination MID upon initialization. Therefore, to connect to the new MID, you must:

1. Modify the mobile application to re-initialize the SDK with the new Application ID (issued from the new MID).

2. Release the updated app to the app store.

3. Prompt your users to install the update.

*Note: The SDK cannot connect to multiple Application IDs simultaneously.

2. Plan for the Transition Period Application updates are dependent on when the user chooses to install them. For a period of time, you will have a mix of users on the old and new app versions.

Users who continue to use the old app will continue to communicate with the old MID. This means that during the transition, contact updates, Inbox/In-App message retrievals, and engagement data (like opens) will be sent to the old MID. You must plan your operations assuming this data will be split across both the old and new MIDs.

3. Consider Importing Data from the Old MID/EID to the New MID/EID As stated above, some users will continue to interact with the old MID, and their subscriber updates will be sent there. If some data is not reflected in the new MID, you may consider using an import function.

However, there is no function designed for a seamless, integrity-assured migration between MIDs. You must perform thorough, advance testing using various test data and scenarios to verify that the data migrates and functions as intended.

At a minimum, the following four pieces of information are required to import into a MobilePush contact list. If this data is not available, you cannot import.

• Contact Key

• DeviceID

• Platform

• System Token

4. Be Aware: Contact Attributes Are Not Inherited by the New App When a user updates the app and the SDK's connection switches to the new MID, attributes for a new environment are issued. Attributes from the old environment become unavailable. There is no feature to transfer them.

To work around this, you must, for example:

• Store the various attributes in your application's own storage (such as a local database or a custom backend database) before the migration.

• After the user updates the app and a connection to the new MID is established, retrieve this stored data and explicitly register it to the new environment using SDK methods like setProfileID() or setAttribute().

5. Inbox and In-App Messages Are Not Migrated There is no feature to migrate Inbox or In-App messages delivered in the old environment to the new one. After the app update, they will no longer be viewable on the user's device.

This is especially critical for Inbox messages, which are often used for announcements that users may expect to remain available. This requires careful planning, such as notifying users in advance that messages will disappear, or performing the migration only after all existing messages have expired.

6. Analytics Data is Also Split Between MIDs Analytics data used for reporting, such as push notification and Inbox message open tracking, cannot be migrated from the old environment. The data will be split at the point of migration, so you must also re-evaluate your reporting and analysis procedures.

Frequently Asked Questions (FAQ)

1. Is there a way to bulk export all device attributes?
A. No, there is no standard feature to export all attributes at once. You can export a filtered list to retrieve many attributes, but some information, such as the System Token, is not included. We recommend implementing logic in your app to send the System Token directly to your own backend database for storage.

2. Can I get the System Token from the _PushAddress Data View?
A. As of this article's publication, this is an officially unsupported Data View. Therefore, Salesforce Support cannot answer questions regarding its details or data retrieval from it.

3. Can the app retrieve attributes stored in Marketing Cloud Engagement?
A. No. The fundamental data flow for MobilePush is one-way: the data held by the app (device) is considered the source of truth, and that data is sent to MCE. It is not possible to retrieve contact data from MCE to the app. If you need a way for the app to retrieve data from a server, you must build a separate backend database and have the app query that.

4. I sent a push notification from the new MID to a user who hasn't updated their app, and they received it. Why?
A. Push notifications can be sent from any environment (even outside of MCE) as long as the provisioning and app implementation are correct and the target device's Token is valid. This is because the push notification mechanism relies on the token issued by the push notification service (APNs, FCM) to handle the delivery request.

5. Can the SDK connect to multiple Business Units (BUs) simultaneously?
A. No, it cannot. It can only be connected to one Business Unit at a time. While it is possible to connect to a different BU by changing the configuration details (such as Application ID, Access Token, and Endpoint) during initialization, communication with the previously connected BU will cease completely. As mentioned in the considerations above, all information will be sent only to the new BU, resulting in data fragmentation. For example, subscriber information and analytics data such as opens will only be sent to the new BU, and Inbox messages from the previous BU will become inaccessible.