Considerations during a CMS Migration

This article provides guidance to newsroom partners of Metrics for News or Source Matters who are going through a CMS migration.

Depending on the extent of changes that happen during your Content Management Service (CMS) migration, updates will need to be made to your Metrics for News (MFN) or Source Matters (SM) settings. This article aims to help you understand the amount of work and time needed to make those updates. If you have any questions or would like clarification on the information below, please create a support ticket.

Step 1: Learn what might change on your website during a CMS migration.

The first step to understand how your migration might impact your MFN or SM account is to understand what will change on your end. We recommend making a list of changes that you are anticipating with the CMS migration.

The following list includes the most common changes to a website undergoing a migration. Not all of them may apply for your scenario, and there may be other types of changes that will happen for you.

1. Article Layout: The HTML or Metadata of your article page template(s).
2. URL Structure: The format of your article page URLs.
3. Paywall Access: The paywall service or restrictions to access on your article pages.
4. RSS Feeds: The limits or format of the feeds that list new articles.
5. Category Taxonomy: The arrangement of topics or tags for your content.

Step 2: Learn what might need to be updated in your MFN or SM account.

There are various settings in our products that import or analyze your content and data that may need to be updated with a CMS migration. The following list includes settings that apply to the list of most common changes above, and may apply to other changes you will go through.

1. Unique Article Identifier: Each article imported into MFN and SM has a unique ID that helps our products differentiate articles and match analytics accurately. In some cases, the unique ID utilizes a portion of the article URL but, sometimes, may retrieve a unique ID from the article page itself. Therefore, a CMS migration may change how we retrieve that unique ID. To ensure no disruption in your dashboards, it is recommended to create a support ticket to notify our team at least seven (7) business days before your upcoming migration and allow us time to review whether your current unique ID will need to be updated.
2. RSS Feeds: If you use RSS feeds to import content into MFN or SM, you may need to update the URL and Fields in the settings for each feed. Tip: Create an additional feed in your settings and use the Preview feature to test whether the feed is compatible.
3. Page Scraping: Settings are required to allow MFN or SM to recognize the Text and Byline of each article. These will need to be updated if the Article Layout will change with your migration. Tip: Append new page scraping settings to your current settings to ensure pre- and post-migration versions of the website will work. Use the Preview feature to test whether the settings are compatible with the new Article Layout.
4. Category Rules: If you have autotagging rules for your content categories in MFN or SM, you may need to update them if your Article Layout or URL Structure have changed. Go to each category option you have saved to your account and review its rules to learn what may need to be updated. Tip: Append new autotagging rules to your current rules to ensure pre- and post-migration version of the website will work.
5. Paywall Access: If you previously had an active paywall for your articles, or will have a new paywall after the CMS migration, it is recommended to create a support ticket to ask our team about whitelisting IP addresses or alternative ways to give our products permission to access your content.

Step 3: Know the timeline during and after the CMS launch

Your goal for the CMS migration is to make it as seamless as possible without disrupting services and products that your organization uses to connect with your audience and staff. The updates to MFN and SM listed in Step 2 above will be helpful to ensure a seamless transition. However, it is important to have a timeline of when those changes need to be in effect and what happens to historical data imported prior to migration.

Timeline of Updates to MFN and SM

The following is a general timeline of how the steps of a CMS migration might be executed and what to consider along the way.

1. CMS migration is approved and scheduled: Woohoo! Congrats! We hope to help you as understand the implications of this migration as you get things started.
   1. Complete Step 1 to understand what might be changing with your CMS migration.
   2. Create a support ticket to notify our team about the upcoming migration and what you know will be changing exactly. We will begin to designate resources on our end to provide you with support along the way.
2. A Staging or Beta website is created for your team to test the new CMS: This separate website is typical to have for all migrations to allow your team to migrate content and settings, and test new functionality.
   
   1. Begin reviewing Step 2 above to learn how you might need to update your settings in MFN or SM.
   2. Once you know the launch date, inform our team to give us a heads up. We can help you monitor incoming content and data to your account before and after the transition.
   3. As you get closer to the launch date, you will want to begin inputting and testing the new settings into your MFN or SM account. We recommend doing so approximately 1-2 weeks beforehand to have time for questions or additional preparation.
3. Launching your new CMS: The transition to the new CMS and sunsetting of the previous CMS.
   1. Monitor your MFN or SM dashboards to ensure content and analytics continue to flow in accurately. If you anticipate measuring analytics or engagement scores differently post-launch, please see the "Historical Data in Baseline Period" section below.
      
   2. Remove old settings to clean up your account configuration and ensure archived settings do not interfere with the new CMS setup.

What about Historical Data in MFN and SM?

Chances are, the content and analytics imported prior to your CMS migration will not be compatible with the new configuration after the migration. This is an expected situation that our products have been built to be adaptive to.

The most common example of incompatible historical data is due to the Unique Article Identifier changing to be different for articles published with your new CMS. This situation may impact how analytics or topics are matched to past articles. For example, as readers engage with past stories, our system may not be able to immediately import the new engagement data into your dashboards. Similarly, changes to the Paywall Access may impact how your analytics and topics are matched.

With these scenarios, as long as the preliminary settings updates from Step 2 above have been made prior to the CMS migration, your historical content and analytics should continue to be accurate and accessible in your MFN or SM dashboards.

Historical Data in Baseline Period

If you anticipate measuring analytics or engagement scores differently post-launch, your scores may be skewed until you update your Baseline Period. This baseline period update may need to take place a few weeks or months after launch when you have enough content that represents average engagement.