Skip to main content
When migrating from one production Curator portal to another, the cutover involves two main changes: updating DNS to route your friendly URL from the current production portal to the new one, and migrating the SAML authentication connection. While DNS changes are straightforward, the SAML migration requires careful planning to minimize downtime and ensure users can authenticate seamlessly after the switch. During the preparation phase before cutover, the new portal will be accessible at a temporary direct URL (e.g., https://new-server.example.com). This temporary direct URL is only needed until cutover is complete. After cutover, DNS will route your friendly URL (e.g., https://curator.yourcompany.com) to the new portal, and the temporary direct URL will no longer be needed.
During this process it can be difficult to tell which portal you are viewing at a given URL, especially once DNS changes are in progress. To make this easier, consider temporarily changing the Curator Site Name on one of the portals so you can visually distinguish between them. This setting is found in the backend under Settings > Curator > Themes > select your theme > Brand tab. For example, you could rename the new portal to “Curator (New)” during the migration. Remember to revert the name after cutover is complete.
This guide presents two options for handling the SAML cutover and provides detailed step-by-step plans for each.

Preparing for Migration: Authenticating to the New Portal

Before you begin the cutover process, you need a way to authenticate to the new portal so you can import content, configure settings, and compare the new portal side-by-side with the existing production portal. There are two approaches for this. Create two separate SAML applications in your Identity Provider (IdP) — one for your current production portal (you should already have this) and one for your new production portal (you will need to create this). Each SAML application in your IdP will point to a different Curator URL:
  • Current production app: Configured with your friendly URL (e.g., https://curator.yourcompany.com)
  • New production app: Configured with the new portal’s temporary direct URL (e.g., https://new-server.example.com)
With both applications in place, your team can authenticate to either portal independently. This allows you to:
  • Import and migrate content to the new portal using Curator’s import/export functionality
  • Verify that analytics integrations, user permissions, and embedded content work correctly on the new portal
  • Compare the new portal’s content and configuration against the current production portal before committing to the cutover
Depending on which cutover option you choose below, the new production SAML app is temporary. It is only needed during the preparation and testing phase. After cutover, the new portal will use the friendly URL and will be served by either the original SAML app (Option 2) or the new (but modified) SAML app (Option 1). The temporary app can then be removed from your IdP.
For instructions on creating a SAML application in your IdP, refer to the provider-specific guides:

Approach B: Use Curator Users on the New Portal Temporarily

If creating a second SAML application is not practical, you can temporarily set the new portal’s authentication type to Curator Users during the preparation phase. This allows testers to log in with locally-created usernames and passwords instead of SAML. To set this up, log in to the backend of the new portal and navigate to the authentication settings. In the backend of Curator using the left-hand navigation, navigate to the Settings > Security > Authentication Settings page. On the Authentication Settings page click the General tab. Set the Authentication Type to Curator Users, then create local user accounts for each person who needs to test the new portal. For details, see the Curator Users guide.
The local usernames and passwords created during this phase are only for the preparation period. They will be abandoned once you switch the authentication type back to SAML — either to stage the changes for Option 2, or during the cutover itself for Option 1. Make sure testers are aware that these credentials are temporary.
You can also temporarily use this approach while waiting for the second SAML application to be set up in your IdP and then switch to Approach A once it’s ready.

Migration Options Overview

Option 1: Swap SAML IdP Configuration

This approach involves modifying the SAML Identity Provider (IdP) to swap the URLs configured in both your current and new production SAML applications at the time of cutover. Advantages:
  • No changes are usually required in Curator during cutover (this depends on the SAML IdP)
  • No changes required on individual user machines
  • Works in all networking environments, including those using Curator’s force domain setting
Disadvantages:
  • The IdP configuration changes are specific to your SAML provider (Okta, Microsoft Entra ID / Azure AD, OneLogin, etc.) and must be coordinated with your SAML administrators
  • More moving parts during the cutover window since both DNS and IdP changes happen simultaneously
  • Cannot be fully staged or tested in advance
See the detailed cutover plan for Option 1 below. This approach involves copying the SAML configuration from your current production portal to your new production portal before cutover, then using local host file entries to test the new portal in advance. Advantages:
  • Fewer moving parts during the actual cutover since SAML is already configured and tested
  • Can be staged and validated in advance of the cutover window
  • No changes required in your SAML IdP
Disadvantages:
  • Requires temporary administrative changes on tester machines (editing the hosts file)
  • Testers cannot access both portals simultaneously while the host file override is active
  • Will not work in environments using Curator’s force domain setting or other networking configurations that bypass local DNS resolution (e.g., split-horizon DNS, internal DNS overrides, or proxy servers that resolve DNS independently)
See the detailed cutover plan for Option 2 below.

Detailed Cutover Plan: Option 1 (IdP Configuration Swap)

This plan involves coordinating DNS and SAML IdP changes during a single cutover window. Because the IdP changes cannot be tested in advance against the new portal’s URL, plan for a brief period of downtime while changes propagate.

Prerequisites

  • Your new production Curator portal is fully configured and tested (content, integrations, users, etc.) with the exception of SAML authentication
  • You have access to your DNS provider to update the friendly URL’s DNS record
  • Your SAML IdP administrators are available and prepared to make changes during the cutover window
  • You have identified the SAML IdP application entries for both your current and new production portals

Pre-Cutover

  1. Confirm your new portal is accessible at its temporary direct URL (e.g., https://new-server.example.com) and all content, integrations, and user configurations are working as expected using a non-SAML authentication method (such as pass-through or Curator Users).
  2. Document the current SAML settings from your existing production portal. In the backend of Curator using the left-hand navigation, navigate to the Settings > Security > Authentication Settings page. On the Authentication Settings page click the General tab. Record the values for Entity ID, SignOn URL, IdP ID, SignOut URL, and the Certificate.
  3. Coordinate a cutover window with your SAML IdP administrators and any stakeholders who need to be informed of the brief downtime.

During Cutover

1

Update DNS

Update the DNS record for your friendly URL (e.g., curator.yourcompany.com) to point to the IP address of your new production portal server. Note that DNS propagation may take time depending on TTL settings. Consider lowering the TTL value in advance of the cutover to speed up propagation.
2

Update the SAML IdP application for the new portal

Work with your SAML IdP administrators to update the application entry that will be used for the new production portal. The URLs in the IdP application (such as the Assertion Consumer Service URL and the Entity ID/Audience URI) need to reference your friendly URL. The specific steps depend on your IdP:
  • Okta: Update the Single sign-on URL and Audience URI (SP Entity ID) in the Okta application settings.
  • Microsoft Entra ID (Azure AD): Update the Reply URL and Identifier (Entity ID) in the Enterprise Application’s SAML configuration.
  • OneLogin: Update the ACS (Consumer) URL and Audience in the OneLogin application configuration.
The exact steps vary by IdP. Consult your SAML IdP’s documentation or work with your SAML administrators for provider-specific instructions.
3

Update the SAML IdP application for the old portal (if keeping it active)

If you intend to keep the old portal running (e.g., as a fallback), have your SAML IdP administrators update its application entry to reference the old portal’s new direct URL instead of the friendly URL. If you are decommissioning the old portal, you can skip this step and remove its IdP application entry entirely.
4

Configure SAML on the new portal

If needed, you may be required to perform a fresh export and import of the SAML metadata from your SAML IdP into Curator if there were changes to certificates or other crucial details that must be reflected within Curator itself.In the backend of Curator using the left-hand navigation, navigate to the Settings > Security > Authentication Settings page. On the Authentication Settings page click the General tab.Set the Authentication Type to SAML and import or enter the SAML metadata provided by your IdP administrators for the updated application. Ensure the Entity ID matches your friendly URL.
5

Verify the cutover

Once DNS has propagated, open a new browser session (or use an incognito/private window) and navigate to your friendly URL. Confirm that:
  • The page loads and shows the new portal
  • Clicking “Log In” redirects to your SAML IdP
  • After authenticating, you are redirected back to the new portal and logged in successfully
  • Embedded analytics content loads correctly
If DNS has not yet propagated to your machine, you may still reach the old portal. Use tools like nslookup or dig to verify that the DNS record has updated before testing.

Post-Cutover

  • Monitor authentication logs on the new portal for any errors. You can view these in the backend under Settings > Event Log or in the system log files.
  • Communicate the completion of the cutover to your users and stakeholders.
  • Decommission or repurpose the old portal once you are confident the migration is successful.

Detailed Cutover Plan: Option 2 (SAML Settings Copy with Host File Override)

This plan allows you to configure and test SAML on the new portal before the cutover window by reusing the existing SAML settings and tricking your local machine into resolving the friendly URL to the new portal’s IP address.

Prerequisites

  • Your new production Curator portal is fully configured and tested (content, integrations, users, etc.) with the exception of SAML authentication
  • You have access to your DNS provider to update the friendly URL’s DNS record
  • You have administrative access to your local machine to edit the hosts file
  • Your environment does not use Curator’s force domain setting, split-horizon DNS, or a proxy server that resolves DNS independently of the local machine

Pre-Cutover: Configure SAML on the New Portal

1

Export SAML settings from the current production portal

Log in to the backend of your current production Curator portal.In the backend of Curator using the left-hand navigation, navigate to the Settings > Security > Authentication Settings page. On the Authentication Settings page click the General tab.Record or export all SAML configuration values:
  • Entity ID
  • SignOn URL
  • IdP ID
  • SignOut URL
  • Certificate
If your portal uses signed SAML requests, also expand the SAML Advanced section and record the Service Provider Certificate and Service Provider Private Key values.
2

Apply SAML settings to the new portal

Log in to the backend of your new production Curator portal using its temporary direct URL (e.g., https://new-server.example.com/backend).In the backend of Curator using the left-hand navigation, navigate to the Settings > Security > Authentication Settings page. On the Authentication Settings page click the General tab.Set the Authentication Type to SAML and enter all of the values recorded from the current portal. If you exported a metadata XML file, you can use the Import SAML Metadata button instead. Ensure all fields match exactly.If your portal uses signed SAML requests, expand the SAML Advanced section and paste the Service Provider Certificate and Service Provider Private Key values as well.Save the settings.
3

Add a host file override on your testing machine

To test SAML authentication against the new portal before updating DNS, add an entry to your local hosts file that maps your friendly URL to the new portal’s IP address.
While the host file override is in place, your machine will route all traffic for the friendly URL to the new portal. You will not be able to access the current production portal using the friendly URL from this machine.
Determine the IP address of your new production portal server.
If your new portal is hosted on Curator SaaS, the IP address is dynamic and may change at any time without notice. This means your host file entry could stop working unexpectedly. If this happens, resolve the current IP address again and update the hosts file entry. Because of this limitation, keep the host file override in place only for the duration of your testing and remove it promptly afterward.
Edit the hosts file on your machine:
  • Windows: Open Notepad as Administrator and edit C:\Windows\System32\drivers\etc\hosts
  • macOS / Linux: Edit /etc/hosts with sudo (e.g., sudo nano /etc/hosts)
Add a line at the end of the file:
<NEW_PORTAL_IP>    curator.yourcompany.com
Replace <NEW_PORTAL_IP> with the actual IP address and curator.yourcompany.com with your friendly URL.Save the file. On macOS, you may need to flush your DNS cache afterward:
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
4

Verify the host file override is working

Before testing SAML, confirm that the host file override is routing your friendly URL to the new portal. Open a new browser session (or use an incognito/private window) and navigate to the backend of your friendly URL (e.g., https://curator.yourcompany.com/backend). Log in and check the Curator Site Name displayed at the top of the page to confirm you are viewing the new portal rather than the current production portal.
This is why temporarily renaming the new portal’s site name (as suggested at the top of this guide) is helpful — it makes it immediately obvious which portal you are connected to.
5

Test SAML authentication against the new portal

Open a new browser session (or use an incognito/private window) and navigate to your friendly URL. Because of the host file override, your machine will connect to the new portal.Confirm that:
  • The page loads and shows the new portal’s content
  • Clicking “Log In” redirects to your SAML IdP
  • After authenticating with the IdP, you are redirected back and logged in successfully
  • Embedded analytics content loads correctly
Since the SAML IdP is configured with your friendly URL, the authentication flow will work normally because your browser is sending requests to the friendly URL, which resolves to the new portal via the host file override.
If authentication fails, verify that:
  • The SAML settings on the new portal match the current portal exactly
  • The Entity ID on the new portal matches what is configured in your SAML IdP
  • The SSL certificate on the new portal is valid for the friendly URL domain
6

Remove the host file override

After successful testing, remove or comment out the host file entry you added in Step 3. This restores normal DNS resolution so your machine can access the current production portal again.

During Cutover

Once you have validated that SAML works correctly on the new portal, the actual cutover is straightforward since the only change needed is updating DNS.
1

Update DNS

Update the DNS record for your friendly URL (e.g., curator.yourcompany.com) to point to the IP address of your new production portal server. As with Option 1, consider lowering the TTL value in advance to speed up propagation.
2

Verify the cutover

Once DNS has propagated, open a new browser session and navigate to your friendly URL. Confirm that you reach the new portal and that SAML authentication works as expected.
Ensure you have removed any host file overrides from your testing machine before verifying, so that you are testing actual DNS resolution.

Post-Cutover

  • Monitor authentication logs on the new portal for any errors. You can view these in the backend under Settings > Event Log or in the system log files.
  • Communicate the completion of the cutover to your users and stakeholders.
  • Decommission or repurpose the old portal once you are confident the migration is successful.