Transition from Rollout to the CloudBees platform

5 minute read

This document is a guide meant for existing rollout.io customers who are migrating to the CloudBees cloud-native platform and its next-generation feature-flag service. A CloudBees representative may have directed you here after provisioning your new tenant and running the one-time data import.

The sections that follow explain what CloudBees has already done, what you can expect during the transition, and the steps you need to complete—sign in, validate your applications, flags, and environments, update your SDK keys, and finish with post-transition clean-up.

Get started

If you are new to the CloudBees platform, skim the documents below for the basics before you begin the transition:

Once you are familiar with the fundamentals, use the table below to review each transition phase at a glance and who owns it. Detailed, step-by-step tasks follow in the next sections.

Milestone Owner Purpose

Email notice

CloudBees

Email announcement of transition from rollout.io to CloudBees Unify (CloudBees platform).

Kick‑off call

CloudBees and Customer

Confirm timeline, tenant name, and special requirements.

Tenant setup

CloudBees

Provision the new platform tenant.

Initial import

CloudBees

Copy applications, flags, and environments into the new tenant.

  • Existing users are not migrated; tenant admins must re‑invite users.

  • SAML/SSO is not migrated; reconfigure SAML in CloudBees platform. Refer to NOTE below.

Initial validation

Customer

Sign in and verify that all data migrated correctly.

Transition

Customer

  1. Update client/server SDKs to version 6.x (refer to Install the SDK). Version 6.x is backward compatible with Rollout, so your existing functionality remains unchanged.

  2. Update your non-production environments by updating the SDK Keys so that your applications point to the platform instead of rollout.io.

Engage CloudBees on the following:

  • Request CloudBees to conduct a refresh sync (which will sync any new flags created on Rollout and update them on the CloudBees platform)

  • Identify features that you use in Rollout that are either different or not on the platform, such as:

    • Specific APIs you depend on

    • Multi-platform feature flags and experiments

    • Set granular permissions on environments and applications

The Initial import does not migrate user accounts or SAML/SSO settings. Tenant admins must re-invite users and reconfigure SAML in CloudBees platform.

Prerequisites

Before working through validating that your feature flags were migrated successfully, and transitioning to the platform, make sure:

  • You have received the email notice and scheduled or completed the kick-off call with CloudBees. The call confirms your timeline, tenant name, and any special requirements.

    For any transition questions, email the CloudBees representative who ran your kick-off call and copy rollout-migration@cloudbees.com, so the team can track your request. Open a CloudBees support ticket only if you need an immediate response because your Rollout account is blocked or your production environment is affected.
  • You have received confirmation from CloudBess that your tenant has been created and the initial import has been completed by CloudBees.

  • You can sign in to the CloudBees platform: https://cloudbees.io.

Customer transition steps

Follow these steps after CloudBees has completed the one–time import.

  1. Sign in to your new tenant using the link provided in the email notice.

  2. Open each imported application and confirm that applications, flags, and environments appear as expected.

    Applications
    Figure 1. Applications
    Flags
    Figure 2. Flags
    Environments
    Figure 3. Environments
  3. Upgrade your client and server SDKs.

    Begin upgrading your server- and client-side SDKs to version 6.x. All 6.x SDKs are backward compatible, so Rollout continues to work during the transition.

  4. Replace your SDK keys.

    Start with your non-production environments and replace your SDK keys in your applications from Rollout to CloudBees platform.

    To locate the new keys in CloudBees platform, navigate to Feature management  Flags. The SDK key for the selected environment appears just below the Flags tab.

    SDK key
    Figure 4. SDK key location

    A common workflow is to update keys in non-production environments first, verify parity, and then change the production keys.

  5. Validate flag behavior in a non-production environment:

    1. Toggle a flag on and off.

    2. Check target-group rules.

    3. Verify that SDK evaluations return the expected values.

    4. Proceed to the next non-production environment until you can validate that all of your environments are working as expected.

  6. Recreate or adjust items that were not migrated automatically (for example, new target groups or properties created after the import).

    The CloudBees transition tool can refresh the CloudBees platform with any new flags you add in Rollout. It performs a one-way sync from Rollout to CloudBees. Request a sync whenever you need the latest Rollout changes.
  7. Post-transition clean-up—archive unused flags, rename legacy items, and delete obsolete environments.

FAQ and troubleshooting

Will CloudBees migrate my flags for me?

Yes. A one-time sync is performed by CloudBees. Additional syncs are available upon request.

What if I used secret mode in Rollout?

Secret mode is supported and improved in the CloudBees platform with UI configuration options.

Can I import flags from Rollout automatically?

Flags are imported as part of our transition script. Our transition script includes the transition of applications, feature flags, and environments.

What happens to my old Rollout account?

Your Rollout account stays online in read-only mode during the transition, giving you time to review settings and compare data. It will be closed once your transition is finished or when Rollout is sunset—whichever comes first. If you need access for a longer period of time, contact your CloudBees transition representative to discuss options.

What if I have devices that don’t regularly receive SDK updates?

Contact us by sending an email to your primary CloudBees contact who initiated the kickoff with you and copy rollout-migrations@cloudbees.com to discuss your options.

How do I set up custom roles?

Please refer to Role-based access control for details.

Do you support SAML?

If you are currently using SAML on rollout.io or want to setup a new SAML connection you can leverage the documentation here: SAML single sign-on (SSO).

What CloudBees platform features can I use after migrating?

You currently have access to all CloudBees platform features. Limits normally align with the Team tier; refer to CloudBees platform pricing. More specific questions can be answered by your transition project lead.

What will happen with my Flag impressions data on Rollout?

Flag impressions data is not part of the transition process. However, you can export impression data using the Rollout API.

What will happen to my audit history on Rollout?

Rollout history is not a part of the transition process.

Although audit history is not officially exportable, an internal API may be available; please contact your CloudBees transition project lead for more information.
What happens to my existing integrations?

Integrations (for example, Jira, GitHub Apps, CasC, webhooks) are not migrated automatically. Some must be reauthorized in the CloudBees platform.

Please alert your CloudBees transition lead to any specific integrations you rely on.
Will my Secret mode settings be migrated automatically when I transition to CloudBees platform?

No. Secret mode settings will not be migrated by default. If you configured Secret mode prior to the migration and want to retain those settings in CloudBees platform, you must contact your CloudBees transition representative to request this. For more information about Secret mode, refer to API introduction.

How can I identify and remove old flags before transitioning to CloudBees platform?

Cleaning up unused or outdated flags before migration isn’t required, but it can simplify the process. Here are some suggestions:

  • Refer to filter stale and inactive feature flags to review flags for possible deletion.

  • Refer to performing cleanup tasks to safely review and delete unused flags.

  • Refer to deleting feature flags once all cleanup tasks are completed and it is safe to delete the flag.

    Other options:

  • Use the use the REST API to use the flag’s endpoint with the includeFlagStatus=true parameter to review flags by status.

  • Use the Impressions API to identify flags that only serve the default value and are not toggling values based on environment or user targeting.

  • Not sure about a flag? Tag it. For example, candidate-for-removal for review after migration.