A quick comparison of 1.0 vs 2.0

1. Stages are milestones in a business process
   
2. Signals receives customer interactions
   
3. Transitions qualifies customer movement through stages
   
4. Actions are business response to customer interactions
   
5. Identifiers help recognize customers in their journey through the process
   

1. Stages are milestones
   
2. Signals capture customer interactions
   
3. Touchpoints are interaction points in your business
   
4. Identifiers help recognize customers and their interactions to map as journeys 

Changes undertaken for 2.0:

Change in nomenclature

1. States are now renamed as Stages for convenience in comprehension.
   STATES ➙ STAGES

Replacements of configuration elements

1. Triggers are replaced with Signals (Zoho’s dynamic event bus service) to capture events with more accuracy and sophistication.
   TRIGGERS ➙ SIGNALS
   Read more: What are Signals?
2. API triggers are scheduled for deprecation and are replaced by Custom Signals.
   APIs ➙ CUSTOM SIGNALS

What does this deprecation mean for your organization?

1. If you have employed API triggers for any touchpoints/ transitions, they will be replaced with the equivalent Custom Signal inside CommandCenter as part of configuration migration.
   
2. As we do not have the visibility of places you have used these APIs in your business, we are unable to replace them in the connection source. We recommend that you replace them before the deprecation date to avoid any disruption in the process of journey capturing.
   
3. After migration, you can view a consolidated list of old vs replaced links (from the top-right of the builder) for your reference. You can copy the new link by hovering over the link to replace it on the connection source.
   
   

Note: The API triggers will continue to work until the deprecation date. This means, if you have associated Custom Signals along with the old API to a trigger, both APIs and Signals will be invoked to move the transition.

Change in module-based behaviors in Journey Builder

1. For each stage, you need to determine the module.
   For example, let’s say you are capturing leads in two different modules: one for leads via submissions and the other to capture visitors stored as records based on the instances. Both these are leads and should ultimately belong to the stage called Leads. However, per 1.0, Stages are module-based and so you had to create two stages as leads from site and leads from submissions.
   
   This created duplication in efforts, and you will not have an accurate measure of the total number of leads captured.

1. Stages are just stages with no dependency on a module in CRM. This means you can bring in customer records from multiple sources like various standard and custom modules and accommodate all of them in one stage. In our example, one stage can accommodate leads captured in multiple modules. This way, the trajectory can be measured from one source.
   
   
   
   As a result of module dissociation, the behavior of record conditions (or, transition conditions) is also updated:
1. In 1.0, conditions for a transition are based on fields from the module configured in the source stage.
2. In 2.0, you can now choose conditions for records in transitions based on modules used in the participating stages.
   From our example: The condition can be based on fields from the leads module or the custom module, or even from the deal module (destination).
   

1. In 1.0, actions are configured for both states and transitions and it created ambiguity.
2. In 2.0, we have made the actions available only for stages. This means that after every transition, an action can be performed on the records upon reaching a stage. There are three types of actions: instant, scheduled, and recurring.

1. In line with the stages’ dissociation from binding to a module, actions are also dissociated. This gives you an advantage of configuring actions for records in the visited stages.
   For example, say you want to send an email to your customers when the production is completed. As you can imagine, production completed is a stage that is built on the factory queue module. To send an update email using 1.0, you had to create another stage called the customer update and connect the Contact Created stage.
2. In 2.0, you can create this action for visited stage (Contact created) from the current stage (production completed) without having to duplicate efforts.
   

You can create an action group specifically for those records in the stage that have come via a specific transition. Say you have a different proposal template for those records that came in via partners; using this option, you can act contextually.

Migrating to 2.0

Subjects for migration

1. Existing configurations of Path Finder and Journey Builder. This includes the configured map, settings, variables, deadlines, Signals, and such.
   
2. Journey records captured and stored in the CommandCenter module.
   
3. Logs and notes saved in the journey.
   

If you are worried that these modifications will affect your existing configurations or will cause data loss or cause any kinds of process disruptions—fret not. There are a few things we would like to clarify before proceeding with the migration:   

Availability of assisted migration

✅ CommandCenter 2.0 is readily available for new sign-ups. Migration is not applicable.

✅ For existing organizations with no usage, the update is auto-migrated gradually. Customer intervention is not required.

⚠️ Organizations that are using either of the CommandCenter tools (Journey Builder or Path Finder) will get the option to migrate displayed in the tools’ list view.

Note:

1. Migration applies only to existing configurations. New configurations created after the date of release, will be created in 2.0’s interface.
   
2. Migration cannot be paused or undone once initiated.
   

Test before you migrate 

1. Opening a Path Finder configuration in preview mode will show you the setup overview. You can access goals and variables from this page.
   
2. Similarly, opening a Journey Builder configuration in preview mode will show you the journey configurations. You can click on the states and transitions to understand how actions and Signals are rendered in 2.0, and explore newer elements like goals and identifiers.
   

Note: Preview mode is a read-only interface. If you attempt to edit it, you will need to migrate to 2.0 to proceed.

 To preview configurations

1. Go to Setup > CommandCenter.
   
2. Access Journey Builder or Path Finder, and hover over the configuration you want to preview, click Preview 2.0.
   
3. You will be taken to the 2.0 interface in preview mode.
   
4. To initiate migration, click Edit and Yes, Migrate to initiate migration right from the preview mode.
   

Types of Migration: 

Bulk migration allows you to migrate all of your configurations to 2.0 at once. You can migrate both Journey Builder and Path Finder configurations in one go, or choose to migrate the configurations of each service separately.

To migrate configurations of both the services in bulk

1. Go to Setup > CommandCenter.
   Migration will be enabled for both the services: Journey Builder and Path Finder.
2. Click on the Migrate to 2.0 button and select Migrate all Journeys and Path Finders.
   
3. In the Confirm migration of all journeys and Path Finders to 2.0 page, click Yes, Migrate.
   

To migrate all Journeys

1. Go to Setup > CommandCenter > Journey Builder.
   
2. Click the Migrate to 2.0 button and select Migrate Journeys Only.
   
3. In the Confirm migration of all Journeys to 2.0? , click Yes, Migrate. 

To migrate all Path Finders

1. Go to Setup > CommandCenter > Path Finder.
   
2. Click on the Migrate to 2.0 button and select Migrate Path Finders Only.
   
3. In the Confirm migration of all Journeys to 2.0? , click Yes, Migrate. 

To migrate configurations individually

1. Hover over the configuration, click Migrate to 2.0.
   
2. In the ensuing confirmation page, click: 
   
1. Preview to preview before migrating.
   
2. Migrate to 2.0 to initiate migration of that configuration.
   
   

List of notifiers you will see as you migrate

1. (Migration in progress) indicates migration in effect
   
2. API error appears for configurations with API triggers, which will be deprecated as of 31st March, 2026, Thursday.
   
3. 2.0 badge indicates the configuration is already created or migrated to 2.0
   
4. Muted Migrate to 2.0 CTA indicates failure in migration. If there is a failure, it will be notified to our automation team to fix it from the backend.
   

View real-time journeys in 2.0

If you are eligible for migration, then your journey captures in the CommandCenter module will display the View CommandCenter 2.0 button on the face of the module. Click this button to view the records in the new UI.

Resources for reference:

CommandCenter in Zoho CRM