# Course: Re-platforming to Sanity https://www.sanity.io/learn/course/re-platforming-to-sanity Learn how to assemble the right team, preempt pitfalls, and move your legacy content to a modern, fast, and structured content platform to take the stress and risk out of even the most ambitious re-platforming project. --- ## Navigation **Track:** [Replatforming from a legacy CMS to a Content Operation System](https://www.sanity.io/learn/track/replatforming-to-sanity) · [View as markdown](https://www.sanity.io/learn/track/replatforming-to-sanity.md) ## Contents 1. [Introduction to re-platforming](https://www.sanity.io/learn/course/re-platforming-to-sanity/introduction-to-re-platforming) · [markdown](https://www.sanity.io/learn/course/re-platforming-to-sanity/introduction-to-re-platforming.md) 2. [Planning a re-platforming project](https://www.sanity.io/learn/course/re-platforming-to-sanity/planning-a-re-platforming-project) · [markdown](https://www.sanity.io/learn/course/re-platforming-to-sanity/planning-a-re-platforming-project.md) 3. [Get comfy with new terminology and technology](https://www.sanity.io/learn/course/re-platforming-to-sanity/get-comfy-with-new-terminology-and-technology) · [markdown](https://www.sanity.io/learn/course/re-platforming-to-sanity/get-comfy-with-new-terminology-and-technology.md) 4. [Re-modelling your existing content](https://www.sanity.io/learn/course/re-platforming-to-sanity/re-modelling-your-existing-content) · [markdown](https://www.sanity.io/learn/course/re-platforming-to-sanity/re-modelling-your-existing-content.md) 5. [Migrating without downtime](https://www.sanity.io/learn/course/re-platforming-to-sanity/migrating-without-downtime) · [markdown](https://www.sanity.io/learn/course/re-platforming-to-sanity/migrating-without-downtime.md) 6. [Conclusion](https://www.sanity.io/learn/course/re-platforming-to-sanity/replatforming-conclusion) · [markdown](https://www.sanity.io/learn/course/re-platforming-to-sanity/replatforming-conclusion.md) --- ## Lesson 1: Introduction to re-platforming https://www.sanity.io/learn/course/re-platforming-to-sanity/introduction-to-re-platforming Why should you re-platform your content? And what can you get out of a re-platforming project? This course is for everyone planning to move out of an old CMS and into a modern content infrastructure like Sanity. Moving the content is but just a part of a successful re-platforming project: A re-platforming project is a great opportunity to structure your content to get more out of it and to sharpen your content workflows and collaboration. This course will give you confidence to plan and execute a re-platforming project. It’s aimed at anyone responsible for—or affected by—such a project. You can also run it as a workshop for your whole team. This course pairs well with the more technical and hands-on [Refactoring content for migration](https://www.sanity.io/learn/course/refactoring-content) and [Migrating content from WordPress to Sanity](https://www.sanity.io/learn/course/migrating-content-from-wordpress-to-sanity) courses. ### Why re-platform your content? There might be many reasons for re-platforming your content, including: - Your current CMS is outdated, insecure, or no longer supported - Your current CMS is too expensive to maintain or upgrade - It's hard to get the right competency for your current CMS/technical stack - Your CMS doesn't allow for content reuse - You want to adopt an API-first content architecture to enable multiple front-ends - You need more flexibility and customization in your content model - You want to improve the authoring experience for your content editors - You're looking to integrate with best-of-breed services for key functionality But such a project might also feel like a massive undertaking with many risks (let's be honest, it can be risky!), especially when you have a lot of existing content, functionality, and integrations that need to be migrated. Thus, a re-platforming project shouldn’t be taken lightly. For the investment to be worth it and pay the dividends you're hoping for, a re-platforming project should help you get more out of your content, let your team move faster, spend more time building and innovating, and spend less time working around or against legacy technology. ### With re-platforming comes great opportunities With some planning and intentionality, a re-platforming project is an opportunity to drastically improve how much you can get out of your content and how efficiently your developers, designers, and content creators can work. So, you can go from reacting to innovating. With this mindset, the project can be exciting! It’s important to stress that even though **every re-platforming project is unique**, there are **common challenges and approaches** that we have seen work for numerous customers of all shapes and sizes throughout the years. This course is built on those experiences. After taking this course, you should be ready to work and move things over from your legacy CMS to Sanity. [Refactoring content for migration](https://www.sanity.io/learn/course/refactoring-content) and [Migrating content from WordPress to Sanity](https://www.sanity.io/learn/course/migrating-content-from-wordpress-to-sanity) are companion courses that teach developers how to do content migrations from other content management systems. These courses will teach transferable skills for migrating from other CMSes like WordPress, Drupal, Adobe Experience Manager, SiteCore, etc. Enough preamble‚ let’s dive in! --- ## Lesson 2: Planning a re-platforming project https://www.sanity.io/learn/course/re-platforming-to-sanity/planning-a-re-platforming-project Feel confident in migrating content to Sanity, equipped with strategies to restructure content, upskill your team, handle legacy data, and validate migrated content for a successful transition. Often, re-platforming projects come as part of a website re-design, and the question soon arises: what to do with the existing content? It might be tempting to write a script to "lift and shift" content from its current origin and give it a new home in the Content Lake with the same structure it had before. Chances are that the CMS you are moving from has locked your content down to "posts" and "pages" and is stored as HTML with presentation-specific code tailored for a design you're trying to get out of. You might also be under pressure to deliver on a tight deadline and maybe with fewer resources than you would prefer. Of course, it’s natural to look for shortcuts! But let’s be circumspect about which of them to take. ## Technology 🤝 practice Re-platforming projects often get approved when people in an organization feel the pain and constraints of their current systems. However, stakeholders may not always recognize that a lack of well-structured content and a cohesive content operation strategy create business challenges that hinder productivity and innovation. **Simply changing technology without addressing these underlying issues may not lead to significant improvements. ** To truly benefit from a re-platforming initiative, organizations should take a holistic approach encompassing the technical aspects, content operations, and the content itself. This involves: 1. Auditing and restructuring existing content to ensure it is well-organized, consistent, and optimized for the new platform. 2. Developing a content strategy that aligns with business goals, user needs, and the capabilities of the new technology. 3. Establishing a content governance framework to maintain quality, consistency, and efficiency across the content lifecycle. 4. Training and empowering content creators and managers to get the most out of the new platform and adhere to best practices effectively. This might seem like a lot, but you can always start doing *some *and allow for iteration as you learn and experience more. There are different ways of scoping each of these, and in many cases, it’s about building habits in your team and organizations – which you do one step at a time. ## An opportunity to restructure Recreating your content structure as-is in a new environment opens the door to recreating your existing problems, just on a new stack. Before initiating the content migration part of the re-platforming project, alternative content models may be beneficial. Could your organization benefit from modifying content that will live in Sanity into different shapes? With different connected references? ### Getting out of presentation lock-in For example, in a default WordPress install, you have just "Posts" and "Pages." Most mature WordPress installations will also have a set of custom types for *Pages* and *Posts*. Many WordPress users use Pages for almost everything and templates as differentiators. A "person" profile might be a "page using the person template." Thus, content is bound by a specific presentation and hierarchy on the website, which stifles reuse and makes it hard or impossible to bring into other channels. ### Adopt structured content With Sanity, you model entities for what they *are*, not what they look *like on the website*. So when migrating, perhaps you split "pages" of content into different document types instead of just importing everything as-is and repeating the same mistakes of the past. > [!TIP] > To learn more about how you can approach a new content model with structured content in mind, you and your team can look into the [Hello, Structured Content](https://www.sanity.io/learn/course/hello-structured-content) course. ## The learning curve New technology may require new skill requirements for your team. If you're coming from a monolith running on PHP, your developer team may need to up-skill with JavaScript to configure the Studio. (Sanity does have a PHP client if you plan to keep your front end there!). Fortunately, developing with Sanity means using the same skills as creating a front end for the web. Developers will recognize many of the same conventions and mental models configuring and customizing the Studio as with the end-user experience. > [!TIP] > To get warmed up and comfy with Sanity, developers can work through the [Day one content operations](https://www.sanity.io/learn/course/day-one-with-sanity-studio) course. While training is *potentially* required for developers, it is *absolutely* required for content creators. Especially when going from a presentation-first to a structured content platform. Don't just ship the finalized new stack and send over the new URL! The most successful re-platforming projects we have seen have taken careful steps to ensure content teams are involved along the journey. In fact, a re-platforming project is best approached as a cross-disciplinary exercise. ## Prepare a cross-functional team Approaching the re-platforming as a team, including product owners, content creators, designers, and developers, helps ensure the success of the project. Anticipate writing new documentation and creating new training materials for content. Keep track of your decisions and the problems they solve. For example, why have some content models changed, or why was the content re-platforming performed at all? This way, latecomers to the project can be brought up to speed quickly. There is a chance that some content will actually *prefer* the legacy platform, mainly because it is familiar—even if it is slow or broken. A re-platforming upsets this familiarity. Your migration team's job is to smooth this transition through involvement, documentation, and education. > [!TIP] > See the [Implementing Sanity successfully](https://www.sanity.io/learn/course/implementing-sanity-successfully) course for more details about building a structured content-ready team. ### Continuous improvement Prepare a feedback strategy so that as developers configure the new platform and migrate into it, authors can interact with preview builds of your Studio and provide feedback. No content model or configuration is perfect the first time. You'll likely find challenges you had not initially planned for at the start of the migration process. Iterate and improve. ## Assess your CMS exit strategy The quality and availability of your existing CMS will determine your migration strategy. You may be coming from a product with a content API like the WordPress REST API, allowing you to run migrations against up-to-date content. This has the massive benefit of not requiring a "content freeze" when you're finally ready to go live on Sanity. Your existing platform may only allow you to export your existing data into local files, like XML, or require you to export content directly from a database. This can make continuous migrations more laborious as manual steps and coordination are involved. Worst of all, your existing system may have no export tooling or database access. Thankfully, web scraping is a viable strategy for retrieving content. Depending on the quality of your existing website's structure, it may provide a stable and predictable method of retrieving rich text, block content, and metadata. However, some tooling may be required to perform the scraping. ### Look for content entropy Content entropy happens over time when a system lacks proper validation and allows for inconsistency. You have to plan how to deal with this. Expect broken links, references to media, images, and users that no longer exist, empty paragraphs, lines with whitespace, and mismatched encoding. Look for content you might not have to move because it no longer serves your and your team's needs. Make a prioritized list of essential content based on its role in the end-user experience and popularity as recorded in website analytics, etc. Selectively choose, clean, and filter all content as it is migrated across. Your migration scripts will need to be written to account for this. Any image fetch that fails needs to be handled. Any referenced documents will need to exist. Anticipate writing verification and error handling in your code. In the next lesson, you'll get introduced to technical concepts and terminology that usually come with re-platforming projects and modernizing technology stacks. --- ## Lesson 3: Get comfy with new terminology and technology https://www.sanity.io/learn/course/re-platforming-to-sanity/get-comfy-with-new-terminology-and-technology Understanding key terminologies and benefits of API-first architecture, and ready to make informed decisions about the right components for your stack. This lesson covers key terminology and mental models in transitioning from a legacy monolith or a headless CMS to a Content Operating System like Sanity. ## Understanding terminology Before starting the migration process, it's essential to understand some critical technical terminology involved with a re-platforming project. Note that the following definitions are written from our point of view and understanding of what makes Sanity different. Adopting this point of view can be helpful when onboarding your team or getting buy-in for the re-platforming project. ### Useful terms to understand **Content Operating System**: You might have been introduced to Sanity as a "Content Management System (CMS)," "Composeable Content Platform," or "Headless CMS." Keen readers might notice that we chose to refer to Sanity as a "Content Operating System." At Sanity, we use the latter because we understand the platform as something broader regarding the problems it solves compared to most (headless) CMSes on the market. Adopting this term also allows your team to think more broadly and deeply about how you accommodate content workflows for your team: *It's so much more than just publishing and distributing content to a website. *Content moves through a life cycle and between systems. **Monolithic Content Management System (CMS)**: A CMS, especially one established in the early 2000s to mid-2010s, where both content publishing and website rendering are done using the same system with a built-in templating engine. They often require developers to be proficient in a backend programming language (like PHP, .NET, or Java) and front-end languages like HTML, CSS, and JavaScript. The content management affordances are often constrained to web publishing and a single website property. **Headless CMS**: A headless CMS decouples the content repository (the "body") from the presentation layer (the "head"). This allows the content to be delivered to any front-end or device over APIs. In many ways, you can think of Sanity Studio as the "Headless CMS" component in your new Content Operating System stack, fulfilling many of the same user tasks. However, unlike most Headless CMSes, it's designed to be configured and customized to fit exactly how you want to work. Compared to "monolithic" architectures, a single server runs an application responsible for storing, enabling editing, and rendering your content. > [!TIP] > See [Headless CMS Explained](https://www.sanity.io/headless-cms) to learn more. **API-first / API-driven**: An Application Programming Interface (API) allows developers to integrate content across systems. CMSes often offer APIs, but that doesn’t necessarily mean that the systems are designed with API use in mind. To be API-first/API-driven, a system is built with the assumption that content will be accessed through an API, and it needs to be interoperable in different systems. This means that content can be created, managed, and delivered entirely via APIs, enabling developers to retrieve content in the structure and format they need. Sanity is built as an API-first platform. ### Potentially confusing or outdated terminology **JAMstack/Jamstack** stands for JavaScript, APIs, and Markup. It's an architecture designed to make the web faster, more secure, and easier to scale. The initial "headless" movement was regularly coupled with references to the Jamstack; however, the term no longer carries real active meaning and has been phased out by vendors that first popularized it. **MACH** stands for “microservices, API-first, cloud-native SaaS, headless” and is mainly used by members of the MACH Alliance, a group of companies and vendors that have paid to be certified and members. While Sanity is not a member of the MACH Alliance, it is based around microservices, API-first, cloud-native, and headless and built on the goal and philosophy of being "composable." **Static Site Generators (SSGs)**: Refers to a class of front end frameworks that exploded in popularity at the beginning of the headless movement (like Gatsby, VuePress, and Eleventy). Made popular in response to server environments, which were slow, expensive, unreliable, and insecure. SSGs prioritized the speed of page loading and security over all else. However, most modern web "pages" are actually web "applications" and so require more dynamic interactions than a "static file" can typically provide. Server environments are now cheaper, simpler, and faster than ever before. Most modern front-end frameworks now prioritize server-side-rendered pages, emphasizing caching and globally distributed assets and servers for speed. You will see fewer references to SSGs in modern website development. **Single Page Applications (SPAs)** are web applications that entirely run in the browser with content and data fetched over APIs. They became popular with the introduction of front-end libraries like Angular, React, and Vue in the mid-2010s, making creating highly dynamic user experiences easier. The trade-off was that they also would require a lot of JavaScript to load and often broke with expected browser behavior (like how the back button works). Modern web application frameworks like Next.js, Nuxt.js, Remix, and Astro allow developers to specify what should run on the server or in the client, depending on a route or a component. ## Benefits of going API-first There are several critical benefits to migrating to an API-first Content Operating System like Sanity – many of these apply to headless CMSes as well: ### More secure API-first architectures reduce the surface area for potential attacks by decoupling the content repository from the presentation layer. The content is delivered to end-users via read-only APIs, making compromising much harder. ### Interoperable With Sanity, all content operations are available via APIs. This allows developers to retrieve and update content in the format and structure they need and integrate it with other systems and applications. ### Enables multiple channels Since content is decoupled from presentation, multiple teams can build distribution channels (website, mobile app, digital displays, etc.) that pull from the same central content repository. This allows for greater flexibility and faster development. ### More technology choices Going API-first opens up many options for front-end tooling and frameworks. Developers can choose the best tools for the job rather than being locked into a monolithic system. ## Potential challenges with adopting a new content stack While there are many benefits to migrating to a Content Operating System, there are also some potential challenges. Being aware of and having a plan for these going into a re-platforming project will help you onboard your team, anticipate concerns from stakeholders, and ensure that the re-platforming is successful. ### It may require new technical expertise API-driven systems typically require different technical knowledge to set up and maintain than traditional website-centric CMSes. With Sanity specifically, you might need to learn GROQ and some specific ways you work with content models. On the positive side, it usually allows your developers to work with one programming language (JavaScript/TypeScript). Customizing the editorial experience will build on the same technologies and mental models as building your front ends, which means less context switching and more productivity. Your content team will likely also need additional training or support from your developers. Since the content operations experience you're creating will be unique to your business, which is primarily a plus, it does make it harder for us to provide learning materials on the specifics of how content operations look in your business. ### Web-based out-of-the-box functionality Web-centric CMSes have built-in website-specific features like redirects, link checkers, and SEO tools. With an API-first CMS, some of this functionality is moved to the front-end layer, and you may need to build it yourself or integrate third-party services. Structuring your content to model what it is rather than what it looks like on a web page unlocks many possibilities beyond your website. Authoring structured content has a longer tail of benefits that will outlast your website's current design. ### Reduced content creator confidence Content creators may feel less confident working in a Content Operating System if they're used to the visual, drag-and-drop interfaces of traditional CMSes. Providing training and establishing transparent workflows is essential to maintain author confidence. Not only should your content team be shown how the Sanity Studio works, but also the network benefits of thinking about your content beyond just your website. Giving your team the ability to preview draft content in the front end(s) can go a long way to ensuring your content team's confidence to press publish. ### Choosing the right services Migrating to headless means carefully evaluating and selecting your content architecture, asset storage, personalization engine, email delivery, and other architecture components. This requires research and planning to ensure that all the pieces work well together. The benefit to API-driven architecture is that should you ever need to migrate off any one part of the stack, it should be a much smaller project than your current one to migrate from a monolith. ## Picking your stack When migrating to an API-driven architecture, you'll need to select the right components to power your stack. Here are some critical considerations for each piece: ### Content Operations Your content architecture is the heart of your content operations. Look for a system with: - A flexible content modeling system to structure your content - Powerful APIs to receive and deliver content from and to any channel - Easy-to-use, configurable authoring interfaces for your content team - Extensibility to customize the CMS to your needs Fortunately, Sanity covers all of this and more! ### Asset storage Sanity stores all your assets into the same dataset as your text content. However, more dedicated providers might be preferable in certain instances. If you have a massive image catalog, integrate your DAM with Sanity using custom asset sources: > [!TIP] > See the documentation about [Custom asset sources](https://www.sanity.io/learn/studio/custom-asset-sources) A dedicated provider will likely offer more options for applications that rely on fast delivery of large amounts of video content. Fortunately, Mux provides a great plugin for integrating videos hosted on its platform. > [!TIP] > See the [Mux plugin](https://www.sanity.io/plugins/sanity-plugin-mux-input) on Sanity Exchange ### End-user forms If your existing solution allows you to create forms, store submissions, and send emails, you must recreate this in Sanity or leverage a dedicated server. The primary role of configuring schema types in Sanity Studio is to create editing forms for *content* in Sanity Studio—not forms for your front end(s). Since you can model anything, you are free to model forms, too! Your front end can write submissions to the dataset using Sanity Client. You can also send notifications using GROQ-powered webhooks. ### Personalization Serving different content to user segments and tracking the results is possible in a headless environment. Still, it will require integrating a service with the context of both your back and front end. Some integrations are available for Sanity, and most personalization providers are API-driven and, thus, can be integrated. > [!TIP] > See the [Amplitude plugin](https://www.sanity.io/plugins/sanity-amplitude) on Sanity Exchange ## Selecting front-end technologies Choosing the "right" front-end is a question without one correct answer. Trade-offs depend on your team's expertise, comfort level with different frameworks, and more. Sanity content can be integrated with any front end technology on any hosting platform. So, this decision mostly has to do with the preferences of your team and your strategy when hiring front-end development talent. For JavaScript frameworks, Next.js is presently the most popular choice and is well-supported through the `next-sanity` toolkit. > [!TIP] > See [next-sanity](https://www.sanity.io/plugins/next-sanity), the toolkit for Next.js applications connected to Sanity Alternative server-rendered JavaScript frameworks include Remix / React Router. On top of this foundation, the Hydrogen framework is designed to work with a tight integration with Shopify for e-commerce sites. If you are building a mobile application, successful Sanity deployments run on Expo for React Native or Flutter for Android. ### Or maybe re-purpose your existing front-end You may already have a front-end that consumes content from an API. If so, you can restructure your content in Sanity and create an API that serves content in the same "shape" your front-end expects. GROQ is the primary way to query content from Sanity and can reshape data as it is queried, but you can also use Sanity’s GraphQL API to integrate content into your front end. With these challenges in mind, let's move into what it means to re-model your content in a re-platforming project. --- ## Lesson 4: Re-modelling your existing content https://www.sanity.io/learn/course/re-platforming-to-sanity/re-modelling-your-existing-content Whether you re-platform your entire application – or just individual pieces – don't miss the opportunity to expand or consolidate a web-focused content database into beautiful structured content. There's a high likelihood that your incumbent, monolithic platform stores content in a way that is tightly coupled to its presentation. If your authors' day-to-day content operations involve building and editing web pages, this re-platforming is a great opportunity to implement structured content to avoid another costly re-platforming in the near future. ## Identify structured content opportunities Consider the following web pages: staff profiles, products, and stores. When thinking about this content in a presentational context—like a website—it's tempting to store all of these as "pages" that use a unique template: "a staff profile web page, a product web page," etc. Avoid trapping content about *what something is* in content models that describe what it *looks like in the front end*. A staff profile should be stored as a "person" document. Product content should be stored in a "product" document. Stores could be stored in a "location" document. All the data within these document types can still be queried into and displayed on a web page; they just don't need to be stored in—or thought of as—web pages inside your Sanity Studio. Where possible, move from presentational thinking towards structured content. Use as few "pages" as possible, and where pages are used, leverage references to individual, meaningful content documents. ### Consolidate duplicate models Depending on the age of your legacy platform, you may also have some similar content models that do not need to be separated. For example, you may have "person" and "staff" records or "office" and "store" records. ## From HTML strings to Portable Text Your existing content—including rich text and block content—may be stored as HTML strings or markdown in flat files or an SQL database. The preferred way of storing rich text and block content in Sanity Studio is Portable Text, an open standard for storing this content in JSON so that it is queryable, filterable, and ... portable. Authoring Portable Text is made simple by the Sanity Studio's Portable Text Editor. However, migrating existing content into the Portable Text standard takes some finessing. This is covered in more detail in [Refactoring content for migration](https://www.sanity.io/learn/course/refactoring-content). ## Consider the SEO impact Remodeling your content can have a profound SEO impact if it also affects the structure of your website. Consider carefully planning for a backend of structured content that renders a consistent, SEO-friendly front-end. Your re-platformed front-end should not create a new link structure without appropriate redirects. At a minimum, you should not only be extracting content from your existing platform but also "crawling" your existing website to record all pages that currently exist and ensure you're recreating those pages or at least redirecting from those that no longer exist to pages that now will. ## Eating the elephant > *"There is only one way to eat an elephant: one bite at a time."* You might not need to re-platform your entire application in one move. To reduce the impact of your initial efforts, identify low-risk content and perform an incremental migration. Prove its worth, and then expand the rollout. Popular content types include legal documents like your terms of service or support pages. These are typically simpler, more static pieces of content that can be easily isolated. In the next lesson, you'll learn more about how to re-platform without imposing downtime and interruption to your services. --- ## Lesson 5: Migrating without downtime https://www.sanity.io/learn/course/re-platforming-to-sanity/migrating-without-downtime Feel confident in migrating content to Sanity with minimal disruption, ensuring data validity, and maintaining SEO standing through effective testing and validation strategies. Beyond the technical tasks of re-platforming, pausing content operations while switching to the new platform frustrates authors and developers. Your migration strategy should account for reducing the time and pressure for all parties on the day you switch. ## Migrating up-to-date content To avoid or minimise a "content freeze", your migration script should be able to run against the most up-to-date version of your current platform's content. Ideally, your migration script should be "idempotent". That is, you can run the script many times, and it will produce the same result. Your import script should create the **same** documents with each run. > [!TIP] > The word "Idempotent" gets a workout in this track, [see Wikipedia for more details on what this means](https://en.wikipedia.org/wiki/Idempotence). This is made possible with Sanity because document IDs can be predetermined, so you can reuse IDs from your existing data source, and each invocation of your migration script will update the same document, not create a new one. These strategies are covered in more detail in [Refactoring content for migration](https://www.sanity.io/learn/course/refactoring-content). ## Validating migrated data Defend your new front-end from errors in advance by validating every document as it is migrated. Runtime validation tooling like Zod can ensure the content you're uploading matches the shape your Sanity Studio schema types are expecting. > [!TIP] > [Zod is a popular library](https://zod.dev/) for validating content in real time, as well as generating TypeScript types. ## Testing back-end data Once your content is in Sanity Studio, you can validate all documents in the dataset against the rules set in your schema types from the command line: ```sh npx sanity@latest documents validate ``` ## Test front-end results For front-ends with a huge content volume, manually checking every page is problem-free may not be scalable. Adding automated testing to your front-end should catch any post-migration errors before your users do. Using a tool that can scan your front-end for errors, downtime, and broken links will likely catch any on-page problems in advance. This is also critical for maintaining a good SEO standing after re-platforming. If you are re-purposing an existing front-end but with a new data source, you may want to integrate a visual regression tool to compare before and after states of every page. --- ## Lesson 6: Conclusion https://www.sanity.io/learn/course/re-platforming-to-sanity/replatforming-conclusion With your re-platforming project planned, technology chosen, and the taking the re-platforming principles and challenges, you should be ready to take on the work. Developers can dive deeper into the technical practicalities of migrating content from a legacy CMS into Sanity: > [!TIP] > The [Refactoring content for migration](https://www.sanity.io/learn/course/refactoring-content) course introduces general development principles and techniques for any content migration. > [!TIP] > The [Migrating content from WordPress to Sanity](https://www.sanity.io/learn/course/migrating-content-from-wordpress-to-sanity) course walks you through the specifics of migrating from WordPress, but can be adapted into other similar CMSes as well. --- ## Related Resources - [Track overview](https://www.sanity.io/learn/track/replatforming-to-sanity.md) - [All courses and lessons](https://www.sanity.io/learn/sitemap.md) - [Complete content for LLMs](https://www.sanity.io/learn/llms-full.txt)