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.
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.Approach A: Create a Second SAML Application (Recommended)
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)
- 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.
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.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
- 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
Option 2: Copy SAML Settings with Host File Override (recommended)
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
- 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)
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
- 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). - 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.
- Coordinate a cutover window with your SAML IdP administrators and any stakeholders who need to be informed of the brief downtime.
During Cutover
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.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.
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.
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.
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
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
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
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.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.Determine the IP address of your new production portal server.Edit the hosts file on your machine:Replace
- Windows: Open Notepad as Administrator and edit
C:\Windows\System32\drivers\etc\hosts - macOS / Linux: Edit
/etc/hostswith sudo (e.g.,sudo nano /etc/hosts)
<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: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.
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:If authentication fails, verify 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.
- 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
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.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.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.