> For the complete documentation index, see [llms.txt](https://doc.batch.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.batch.com/getting-started/other/implementation-guides/mep-to-cep-migration/how-to-prepare-for-the-migration-from-the-mep-to-the-cep-for-crm-teams.md). # How to prepare for the migration from the MEP to the CEP? (for CRM teams) Migrating from the **Mobile Engagement Platform (MEP)** to the **Customer Engagement Platform (CEP)** is a major step forward.\ It allows you to manage all your engagement channels (push, in-app, email, web push) from a single dashboard, powered by a unified user profile and real-time orchestration. While the technical migration (SDKs, APIs, connectors) is handled separately, this guide focuses on **what operational teams need to do** to get ready for the switch. {% hint style="info" %} If you are looking for the **technical migration checklist**, you will find it [here](https://doc.batch.com/getting-started/other/implementation-guides/how-to-get-ready-to-migrate-from-the-batch-mep-to-the-cep). {% endhint %} *** ### 1. Validate your data and tagging plan Once your user profiles are synchronized, the first step is to **validate your data**.\ From the **Profile Data** section, you can now check which attributes and events are available for each platform (Android, iOS, Web).
Each data point includes a **source indicator** by platform.\ Make sure that your key events (such as session starts, purchases, and subscriptions) are consistent across all platforms. Validated data will be available for **segmentation** and **trigger automations** later. {% hint style="warning" %} Validate your tagging plan before creating new campaigns. This ensures that all data used for segments and automations is fully synchronized. {% endhint %} *** ### 2. Create shared labels across all platforms Labels in the CEP are **cross-platform**.\ This means a single label can be used from Mobile and Web pushes to Email or SMS, making campaign organization and reporting much simpler. Navigate to the **Labels** tab and recreate your existing labels there.\ You will be able to filter, group, and report on campaigns more easily than before.
**Why labels matter**\ Labels are key to keeping your campaigns organized and measurable. They let you classify, search, and report across all campaigns, regardless of channel or platform. Well-structured labels also power **cross-platform analytics** and simplify **capping** and **performance tracking**.\ Learn more about label management in the [Labels documentation](https://doc.batch.com/getting-started/features/customer-engagement-platform/settings/labels). *** ### 3. Define cross-platform capping rules Once your labels are ready, it is time to define your **capping rules**.\ Capping now works across all platforms, ensuring users won’t receive too many notifications regardless of the device they use. You can create your new rules in the **Capping** tab.
{% hint style="warning" %} If you set a capping rule of 2 messages per day, a user receiving a web push and a mobile push counts as 2, even if they’re on different platforms. {% endhint %} *** ### 4. Create dynamic segments for recurring audiences Segmentation has been completely redesigned in the CEP.\ You can now create **dynamic segments** that automatically update based on real-time user data.\ These segments can then be reused across multiple campaigns or automations. 1. Go to the **Segments** tab. 2. Create your audiences using the filters and attributes you validated earlier. 3. Save them for recurring use in campaigns.
{% hint style="warning" %} Use dynamic segments for recurring audiences like “Active users last 7 days” or “Users with push enabled.” {% endhint %} *** ### 5. Set your delivery speed (Send Rate) The **Send Rate** (delivery speed) sets the maximum speed at which your messages are sent.\ It works like a speed limiter, ensuring the system never sends faster than the configured rate. The actual speed may vary depending on system load or network conditions.\ This helps you manage server load and control pacing during large-scale message sends. You can adjust the send rate from the **Push Settings** tab when creating or editing a campaign.
*** ### 6. Replicate your recurring campaigns to the CEP Recurring automations created in the MEP can be easily migrated to the CEP.\ Use the **Replicate on CEP** button available in your MEP campaign forms. Once replicated, you will be able to manage these campaigns directly in the new dashboard, using the unified CEP interface.
{% hint style="warning" %} Review the mobile landing, label, and segments once replicated; these may differ slightly depending on your new setup. {% endhint %} *** ### 7. Replicate your trigger automations to the CEP Trigger automations are now orchestrated from the **Omnichannel** section of the dashboard. ![](/files/CLgknfBw9OEQykUscfHX) Trigger automations previously created in the MEP can now be directly migrated to the CEP. To do so: 1. Go to the **Automations** **V1** tab and open the trigger automation you wish to migrate. 2. Click the **Actions** drop-down menu in the upper right corner. 3. Select **Replicate in CEP**.
Once replicated, you will be able to manage your automations from the Omnichannel section of the dashboard, using the full CEP orchestration capabilities. {% hint style="danger" %} Do not copy-paste dynamic content from the MEP to the CEP. {% endhint %} When migrating your **push automations** from the MEP to the CEP, avoid copying and pasting message content that contains **personalization variables** (e.g., `u.optin_compositionbox_pushnotif`, `triggerEventAttr`, etc.). The CEP uses a different syntax and variable engine.\ If you copy/paste MEP content directly, your personalization rules (conditions, variables, or fallback values) will **not display correctly** during tests or live sends. **✅ What to do instead** * **Reinsert all personalization variables** manually using the **Insert Variable** button in the CEP editor. * You **don’t need to modify** or remove prefixes, such as `u.` because these were part of the MEP’s template language and are handled differently in the CEP. * Ensure the attributes you use exist in your **CEP data model**. Native attributes now use the prefix `b.` (for example: `b.my_native_attribute`). {% hint style="warning" %} If you are unsure whether an attribute is available in the CEP, check the *Profile Data* tab. {% endhint %} For a full overview of what is and is not transferred during replication, visit the [Trigger Automation Replication guide](https://doc.batch.com/getting-started/other/implementation-guides/mep-to-cep-migration/how-to-replicate-your-trigger-automations-from-mep-to-cep). *** ### 8. Replicate your In-App automations to the CEP In-App automations created in the MEP can now be directly migrated to the CEP.\ Use the **Replicate on CEP** option available in the **Actions** menu of any running or stopped MEP In-App automation. The tool automatically maps the following elements across MEP and CEP: * Targeting (country, language, custom attributes, event targeting, native attributes) * Trigger event and timing * Capping and grace period * Message content, advanced settings, tracking ID, and actions * A/B tests and multi-language setups Once replicated, the automation is tagged **"Migrated"** for easy tracking, and can be managed directly from the **Omnichannel** section of the dashboard. {% hint style="warning" %} **Review visual rendering after replication.** The tool replicates structure and content, but spacing, image sizing, font sizes, and button alignment may differ between MEP and CEP. Always review and adjust your In-App design before activating. **Secondary actions are not migrated.** If your In-App relies on events generated by secondary actions, these will no longer be triggered after migration. Adapt your In-App to handle this with Retargeting where possible. {% endhint %}
{% hint style="danger" %} **Important** If migrating from In-App v1 to v2, you must manage this transition carefully to avoid disruption. * Activate the *Switch to In-App v2* flag only when a sufficient number of users have migrated to **SDK 3.1 or later**. * You can estimate this share using the **estimated reach** feature, which filters out users running an older SDK version. * Once the flag is activated, users on the new SDK version will receive CEP In-App automations, while users on older SDK versions will continue to receive MEP In-App automations without interruption. * **No rollback is possible:** once the new endpoint is serving v2 In-App automations, you cannot revert to v1. {% endhint %} For a full overview of the new In-App features and capabilities, [see the In-App documentation](https://doc.batch.com/getting-started/features/customer-engagement-platform/orchestration/in-app-automations). *** ### 9. Review the final checklist before launching campaigns ✅ Validate your tagging plan\ ✅ Create shared labels\ ✅ Define capping rules\ ✅ Build dynamic segments\ ✅ Set your delivery speed\ ✅ Replicate recurring campaigns\ ✅ Recreate triggers in Omnichannel\ ✅ Prepare new In-App templates Once these steps are complete, you are ready to launch your first campaigns on the CEP. *** **Next steps:** * [Read the full technical migration checklist](https://doc.batch.com/getting-started/other/implementation-guides/how-to-get-ready-to-migrate-from-the-batch-mep-to-the-cep) * [Explore CEP trigger orchestration](https://doc.batch.com/getting-started/features/customer-engagement-platform/orchestration/trigger-automations) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://doc.batch.com/getting-started/other/implementation-guides/mep-to-cep-migration/how-to-prepare-for-the-migration-from-the-mep-to-the-cep-for-crm-teams.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.