Understanding the migration from Hub and Spoke to Multibrand (Enterprise) Follow

enterprise plan

This article is for Enterprise customers who are currently using a Hub and Spoke setup to manage multiple brands, and are considering migrating to Multibrand to manage multiple brands.

Prerequites for migrating to Multibrand

As you are thinking, or even planning, to migrate from Hub & Spoke (H&S) to Multibrand (MB) please review these key roadblocks which will prevent us from fully migrating your account to Multibrand.

Before you read the details, ask yourself if you are really using all of your spokes. We have customers who have set up Hub & Spoke but are only using the Hub. If your Spokes are not being used, or the Spokes are not sharing tickets with the Hub, then it is likely that you do not need a migration.

  • Help Center communities Although this is likely to change in the next months, we cannot currently migrate Help Center Communities content. So you will be required to leave that content behind or recreate it manually.
  • Multibrand or Hub & Spoke A Multibrand instance cannot exist within a H&S setup. These products are mutually exclusive.

If you are comfortable with all the above, and you want to know more about the multibrand migration, please start with the article The road to Multibrand migration.

Comparing Hub and Spoke to Multibrand

This section outlines the change in behavior a Hub & Spoke (H&S) might encounter after migrating to Multibrand. We have plans to change of the Multibrand behavior for some of the items below but we do not have a specific timeline on those yet.

  • Remote Authentication/Single Sign On Each Help Center redirects users to the same Single Sign On protocol and database. This is a side effect of the fact that users are per account, not per brand.
  • Chat channel branding Tickets created through Zendesk Chat are not currently aware of the brand attribute. Again, we intend to correct that in the future. In the meantime, improve the Chat multibrand setup by implementing a subset of the suggestions in the article Multibranding Zendesk Chat.

  • Agent signatures There is only one signature per agent. Agents can leverage personal macros to create an agent signature for each brand.
  • End user brand identities There is currently no way to segment end-users for customer lists or NPS reports based on brand identity because we do not track which of your users has interacted with which of your brands.

  • Agent permissions All agents have access to all brands by default. You can create brand views for agents to use. If restriction is required, use triggers to assign brand tickets to groups and restrict agent permissions to tickets in those groups.
  • End User permissions You cannot hide certain Help Centers to a subset of your end users. This is by design, but we’re working on a way to support segmented and privileged service based on user type. However, it is possible to prevent access to content, user portal, and communities by using Zendesk user tags and javascripts.

  • Single email templates At launch you will be limited to one html template per account. We plan to update this in the future, but for now you can create a shared HTML template and use macros to brand the text of their responses

  • Ticket forms At present your ticket forms appear in every Help Center. We plan to create branded ticket forms in the future. For now, you can show/hide specific ticket form per Help Center by using javascripts in your respective Help Centers.
  • Integrations We are working to make sure that the brand value translates over in our major integrations, including JIRA and SFDC. All other apps will need to be updated by their owners.

  • Password reset and Welcome email If an end-user requests a password reset from one brand portal, they will reset the password for all brands simultaneously. The password reset and welcome emails aren’t customizable, but it will list all associated Help Centers so the end-user is aware of all the brand that the login and password reset applies.

Understanding the steps and limitations of the migration

Here are the key elements of the Multibrand migration:

  • Steps and timeline

  • Limitations

Typical steps and timeline

  1. Zendesk prepares your Multibrand instance.
  2. Zendesk migrates a sample of the content (tickets and HC articles).
  3. You will verify that the sample content was migrated as expected.
  4. Zendesk will complete the migration of content except for tickets less than closed (i.e. tickets which are in "flight").
  5. You will fully configure your Multibrand instance which includes workflow (macros, triggers, automations, and views) and all other settings.
  6. You will prepare for switchover by communicating with your customers about the upcoming downtime.
  7. You and Zendesk will execute the downtime tasks: Zendesk to migrate the remaining tickets and you will switch subdomains (from Spoke to Multibrand), set host mapping for each brand, and SSL.
Note: Downtime is directly related to the number of tickets which are less than closed in each spoke. We can typically migrate 35,000 ticket per hour. If a downtime is not possible, we can also migrate you to Multibrand without incurring downtime but it requires changing your support email addresses and the URL of your Help Centers.

In terms of timeline, this effort is bounded by the Zendesk resources in place for this process, migration complexity of your program, and your responsiveness in completing your tasks. Only after gathering your migration requirements will we be able to tell you what is the expected completion date for your migration.

Current migration limitations
  • Tickets
    • We migrate all comments, attachments, and metadata (i.e. the current value of every ticket field and tags)
    • We cannot migrate the events (i.e. tag "xyz" was added by trigger 123 on Dec.12, 2014)
    • Ticket # ID cannot be migrated as new tickets are created in the Multibrand instance.
    • Voicemail and voice recordings are not migrated.  However, we give you a complimentary access to your old Zendesk instances for reference.
  • Help Center content
    • We migrate articles (and Help Center attachments). Every article will have the same author after the migration (the account owner or a person you designate).  
    • Article creation date, comments, and subscription are not available. So it is for Section's settings and Communities content.
    • Templates cannot be migrated (i.e customization made to your Help Center)
    • Category or Section settings cannot be migrated.  You need to reset them after the migration.
    • Category, Section and Article # IDs will change upon migration. Any previous external links will need to be updated.
  • User information
    • We do not migration Organizations information.
    • End-user, agents, groups, and organization can be migrated (it does not include custom fields, user notes and details on the above information)
    • End-user passwords cannot be migrated. So if your customers are logging into Zendesk directly (i.e. has an authentication profile with Zendesk), then your customers will need to reset their password once after the migration is completed.
    • Agent roles is not migrated.
    • Org, lang, time zone, Details + Notes, and custom fields on the profiles are not migrated.
  • Workflow
    • Macros can be migrated upon your request.  We migrate the text located in all Global and Group macros.
    • We cannot migrate your views, triggers, and automations. You need to review these elements and adjust them for the new brand you have created.
    • Dynamic content is not available for migration
  • Other
    • Insights reports do not get migrated
    • Satisfaction ratings: not available
    • Migration of "Settings" and "Channels" are not available (and it would not make much sense given the additional brands.
    • Bookmarks to specific articles will send user to branded Help Center homepage (not to the equivalent article in the new branded Help Center)
    • We are working to make sure that the brand value translates over in our major integrations, including Jira and SFDC. All other apps will need to be updated by their owners.
Have more questions? Submit a request


  • 0


    Has this changed since the article was written:

    • Help Center communities Although this is likely to change in the next months, we cannot currently migrate Help Center Communities content. So you will be required to leave that content behind or recreate it manually.

    We currently have Hub/Spoke and want to implement your community.  At some point I'm assuming that you will do away with Hub/Spoke which means we need to move to Brands.  I do not want to lose community data should that happen.

    I would prefer to not have to move to Brands at this time so I'm kind of stuck.

    Is there any End-of-life plans for Hub/Spokes?


  • 0

    Hi Rosanne!

    I don't have any information on EOL for Hub/Spoke; I wouldn't worry about it for the moment. We generally give ample time for people to prepare when we decide to deprecate something.

    That said, in the event that you end up needing/wanting to switch to Brands, we have recently rolled our Community API to augment the existing Help Center API, which previously only worked with Knowledge Base content. You'll be able to use that API to pull your Community content and push it to your new Community. It's important to note, though, that you'll need to be on Community v2 in order for that to work. If you'r'e not sure what that is or whether you have it, you can get more information here:

    Please let me know if you have any other questions!

  • 0

    Awesome Jessie. Thanks for letting me know!

  • 0

    Happy to help!

Please sign in to leave a comment.

Powered by Zendesk