DEV Community: Mariusz

Best Use Cases of Sanity CMS: Features, Pricing & Implementation Guide

Mariusz — Sat, 18 Jul 2026 20:08:00 +0000

TL;DR

Best Sanity CMS use cases include enterprise multilingual websites, media & publishing platforms with high editorial volume, e-commerce product catalogs with dynamic attributes, learning management systems with interactive content, and custom internal tools or dashboards tailored to specific business processes.
Sanity enables structured content schemas for complex data modeling, real-time collaboration and live editing for distributed teams, GROQ-powered flexible queries that overcome traditional API limitations, integrated asset management with global CDN delivery, and webhooks with ISR revalidation to keep Next.js sites performant and up-to-date.
Core strengths: clean APIs with GraphQL-like flexibility, instant visual previews, outstanding editor experience, proven scaling for thousands of documents, and significantly lower backend maintenance than legacy CMS platforms.
Sanity shines in React/Next.js projects that require flexible content modeling, seamless live previews (Draft Mode support), automatic ISR integration, and custom editorial interfaces without rigid templates. It fits teams that prioritize developer freedom (custom plugins, GROQ), editorial efficiency (intuitive interface), and future-proof composable architecture that scales from MVP to enterprise without painful migrations.

Introduction

Sanity has established itself as a leading player in the headless CMS market, holding a meaningful share of the headless CMS space and trust from businesses around the world, per Web Tech Survey's market breakdown (where Sanity trails category leaders like Contentful and Ghost but leads platforms like Prismic). It's a composable content cloud designed to empower both technical and non-technical teams. Sanity best use cases can range from retail websites to knowledge repositories for medical companies. Strong APIs, customizable workflows, and an advanced visual editor make it a great choice for projects that need to be flexible and performant.

Pagepro has worked on a wide range of Sanity projects, like enterprise websites or large-scale applications with custom workflows, and has seen how Sanity improves content management. This article details Sanity's best use cases, exploring the features and advantages that make it the right fit for many types of websites.

What is Sanity CMS?

Sanity is a headless, API-first content management system built around the idea that content should be structured data — not locked inside a templated interface. Instead of managing HTML pages, you manage content as discrete, reusable pieces that can be delivered to any frontend, app, or platform through clean APIs.

At its core, Sanity consists of two parts:

Sanity Studio — a fully customizable content editing environment built in React, where your team creates, edits, and organizes content daily.
Content Lake — a cloud-hosted database that stores all your content as structured data and serves it in real time to any channel or platform.

Developers define the content schema in code, which means the editing interface reflects exactly what a project needs — nothing more, nothing less.

What separates Sanity from traditional CMS platforms like WordPress is where control sits. In WordPress, the CMS owns the presentation layer — themes, page builders, and plugins shape both how content is managed and how it's displayed. In Sanity, the frontend is entirely decoupled. Your content lives in one place and can power a Next.js website, a mobile app, a digital kiosk, or all three simultaneously, without duplicating or reformatting anything.

Sanity also uses GROQ (Graph-Relational Object Queries), its own query language that gives developers fine-grained control over exactly what data gets fetched and in what shape. For teams used to REST APIs returning overfetched payloads, this is a meaningful improvement in both performance and developer experience.

Here's what makes Sanity stand out from other headless CMS options:

Fully customizable Studio — adapt the editing interface to your exact workflow, not the other way around.
Real-time collaboration — multiple editors can work on content simultaneously without conflicts.
GROQ querying — fetch precisely the data you need, reducing payload size and improving frontend performance.
No vendor lock-in on the frontend — connect Sanity to any framework, including Next.js, Astro, or SvelteKit.
Scales without migration — the same setup that works for an MVP handles enterprise-level content volume.

Sanity has moved well beyond the "developer experiment" stage, with adoption by companies like PUMA, Eurostar, and Morning Brew. It's production-grade infrastructure for content at scale.

The Flexibility of Sanity: More Than a Headless CMS

Sanity is a Content Operating System that adapts to your business requirements. It has all the features of a modern headless CMS designed for high-traffic environments and demanding enterprise workloads. At the same time, it stays flexible enough for projects of any size.

What sets it apart from other CMSes is its ability to fit into your workflows. Unlike other solutions, it doesn't force you into rigid templates, plugins, or pre-defined structures.

While many CMSs focus only on content management, Sanity prioritizes the developer experience, providing exposed APIs that allow you to integrate with any system or tool.

What is Sanity Studio?

Sanity Studio is a customizable content workspace that lets teams create, edit, and organize content for websites and apps. It's the heart of your content management and where editors collaborate to keep it up to date.

Since it's React-based, developers can tailor it to your needs, while editors get a clean and fast environment for daily work.

What is Content Lake in Sanity?

The Sanity Content Lake is a cloud database and central hub where all your content is stored, updated, and delivered in real time. Every piece of content is stored as structured data, so it's easy to query, version, and reuse across websites, apps, and any other digital product.

Since it's fully managed by Sanity, there's no need to maintain servers or worry about scaling.

Top 3 Use Cases for Sanity

Use Case 1: Use Sanity for Enterprise Websites at Scale

One of the best uses for Sanity is managing content for enterprise websites.

In one Pagepro project, a global corporation operating across multiple regions with complex content requirements chose Sanity for their website. The site housed multilingual content, region-specific pages, blogs, landing pages, and resource hubs. Each region's team needed tailored access to manage their localized content securely.

Sanity's multi-language support allowed all this content to reside in a single dataset, saving on costs and simplifying data management. By integrating with Azure Active Directory for SSO, the headless CMS ensured enterprise-grade security and intuitive user management. Sanity's APIs delivered consistent performance, even under heavy traffic.

Why Sanity Is the Best Choice for Enterprise Websites

Multi-Language and Localization Support — manage multiple languages and regions in a single dataset to reduce costs.
SSO Integration for Security — integrate with authentication systems like Azure Active Directory for secure and efficient user management.
Granular Roles and Permissions — provide access for regional teams and specific content management tasks.
High Performance at Scale — handle high-traffic demands without compromising site speed or reliability.
Flexible Content Lake — adapt to the complex data structures required by global enterprises.
Real-Time Collaboration — allow multiple teams to collaborate on content at the same time.
Enhanced Preview Capabilities — provide real-time previews for content teams to improve output quality before publishing.
Cost Efficiency — avoid additional charges for extra datasets.

Use Case 2: Media and Publishing Platforms

One platform Pagepro worked on hosted tens of thousands of structured medical content pieces with complex relationships and compliance needs. Sanity can handle such complexity easily, but in this project it was chosen for its adaptability.

The client's legal obligations required a longer content history than the default 90 days. Using Sanity's exposed APIs, Pagepro customized history retention to meet compliance standards. Real-time collaboration enabled editors to work simultaneously, and custom workflows allowed every piece of content to pass through proper approval channels.

Why Sanity Is the Best Choice for Media and Publishing

Scalability for High-Volume Content — manage thousands of structured content pieces with complex relationships and dependencies.
Custom History Retention — extend version history to meet regulatory and compliance requirements.
Real-Time Collaboration — enable simultaneous editing by multiple users.
Content Relationships — model intricate relationships between content types.
Integration Capabilities — use APIs to connect with analytics tools, external platforms, or legacy systems.
Snapshot Generation — provide visual documentation of content states for audit or archival purposes.

Use Case 3: Custom Workflows for Large Applications

In another project, Pagepro implemented a workflow where content creation and verification were managed through custom tools.

Integrating AWS Cognito with Sanity enabled a user-friendly admin panel, making the verification process easier without exposing sensitive AWS settings to end-users.

Another example of customization was the use of AI-powered translation. As soon as a document was published, translations for multiple languages were generated automatically — showing that Sanity supports innovation without the need to build a custom CMS from scratch.

Why Sanity Is the Best Choice for Large Applications

Exposed API for Customization — build tailored workflows and integrations to match unique business requirements.
AI-Powered Features — automate processes like translations and content repurposing for efficiency.
User-Friendly Custom Panels — simplify workflows with bespoke admin interfaces.
Content Repurposing — utilize the same content across multiple platforms, including web, mobile, and more.
Third-Party Integrations — connect with external tools like AWS, analytics platforms, and CRMs.
Rapid Development — use Sanity's tools to create solutions faster than traditional custom CMS builds.

Other Use Cases for Sanity CMS

Marketing Websites

Sanity Studio is a great asset for marketing websites. Its visual editing experience rivals competitors like Storyblok, letting content creators build visually rich landing pages with reusable content blocks. It's a popular choice for businesses focused on creating dynamic and engaging experiences.

Why Sanity Is the Best Choice for Marketing Websites

Block-Based Content Editing — empower content teams to create and reuse predefined blocks for efficiency and consistency.
Enhanced Visual Editor — offer previews for a better content creation experience.
Customizable Studio — adapt the interface to meet specific branding and workflow needs.
Collaboration-Friendly — streamline marketing workflows with real-time collaboration and role-based access control.
Integration-Ready — connect with CRM, analytics, and marketing automation tools.

E-Commerce Platforms with Sanity as Headless CMS

Online stores benefit a lot from Sanity's integration with Shopify and other e-commerce tools. It adds value to e-commerce platforms by improving product information management and supporting relationships between products.

Why Sanity Is the Best Choice for E-Commerce

Product Information Management (PIM) — centralize product metadata for consistency across channels.
Shopify Integration — improve workflows for product descriptions, categories, and relationships.
Scalable API — handle high-traffic e-commerce demands with no effort.
Customizable Data Models — adapt product catalogs to unique business needs.
Seamless Multi-Channel Support — use the same product data for web, mobile, and other channels.

Learning Platforms

When it comes to managing educational content, Sanity provides the flexibility learning platforms need to implement functions like tracking user progress and delivering multimedia learning materials.

Why Sanity Is the Best Choice for Learning Platforms

Structured Content Management — organize lessons, chapters, and quizzes with ease.
Progress Tracking — store user progress data to personalize learning experiences.
Scalability — handle large volumes of content and users.
API-Driven Delivery — integrate with learning management systems (LMS) and mobile apps.

Mobile App Backends

The ability to handle data communications with apps, API focus, and customizability are huge advantages for devs working with Sanity. It's a good option for a mobile application backend.

Why Sanity Is the Best Choice for Mobile App Backends

Fast Setup — quickly configure backends for mobile apps.
Scalable API — ensure consistent performance for high-traffic applications.
Customizable Workflows — tailor data structures and workflows to app-specific requirements.
Multi-Platform Compatibility — share data across web, iOS, and Android apps.

Final Thoughts

Choosing a CMS is a strategic decision, especially for technical leaders managing complex projects or scaling businesses.

Sanity's impact on content management enables frontend teams to work smarter and faster. The combination of flexibility, strong APIs, and intuitive user experience makes it a great fit for many businesses.

Sanity use cases range from enterprise websites to e-commerce platforms and custom applications.

FAQ

What is Sanity.io?

Sanity.io is a Content Operating System offering teams a flexible way to create, manage, and deliver content to any website or application. It uses structured content stored in the Sanity Content Lake and a customizable editing environment called Sanity Studio. Developers can tailor the entire workflow, while editors get an intuitive platform to update content in real time.

Is Sanity a headless CMS?

Sanity is a headless CMS, but it goes beyond the traditional definition. It functions as a content operating system — providing structured content storage, a fully customizable editing environment, real-time collaboration, and APIs that let you deliver content to any channel. The key difference is that Sanity is designed to adapt to your workflows and data structures, rather than forcing you into predefined templates or rigid content models.

How does Sanity work?

Sanity separates content from your frontend and delivers it as structured data through APIs. Content creators use Sanity Studio to edit and manage content, while the Sanity Content Lake stores everything in the cloud and updates it in real time. Developers then pull that content into websites or apps using Sanity's APIs, giving full control over how and where the content is displayed.

What is Sanity used for?

Sanity is used for managing and delivering content across websites, mobile apps, e-commerce platforms, and custom digital products. Its most common use cases include enterprise websites with complex content structures, media and publishing platforms with high editorial volume, and large applications that require custom workflows and integrations. Pagepro has used it across projects ranging from global multilingual websites to medical content platforms with tens of thousands of structured documents.

What is Sanity good for?

Sanity best use cases include marketing sites, e-commerce, blogs, product catalogs, and apps. It's great for any project that needs flexible, well-structured content and a smooth editing experience.

Is Sanity free?

Yes, Sanity has a free plan you can use indefinitely within the included usage limits. It gives access to all core features including real-time collaboration, unlimited content types, and Sanity Studio. For projects that grow beyond those limits — in terms of API requests, bandwidth, or team size — paid plans are available with transparent usage-based pricing.

Is Sanity open source?

Sanity Studio is open source and available on GitHub, which means you can inspect the code, build custom plugins, and contribute to the ecosystem. The Content Lake backend, however, is a managed cloud service and not open source. This distinction matters for teams with strict data residency or self-hosting requirements.

What companies use Sanity?

Sanity is used by companies including PUMA, Morning Brew, Eurostar, and Amplitude — organizations that need structured, scalable content workflows across multiple channels. Its adoption spans industries from retail and media to healthcare and financial services, reflecting its flexibility across very different content requirements.

How much does Sanity cost?

Sanity offers a free plan that covers smaller projects and includes real-time collaboration, unlimited content types, and sufficient API and bandwidth quota for personal projects or low-traffic sites. Paid plans — Growth and Enterprise — unlock higher usage limits, advanced access controls, custom SSO, and dedicated support. Pricing scales with usage rather than seat count, which makes it cost-effective for teams that need flexibility without paying for unused capacity.

Sanity vs WordPress — which should I choose?

The right choice depends on your project's complexity and team setup. WordPress is the better fit for straightforward content sites where non-technical users need a familiar, plugin-rich environment without developer involvement. Sanity is the stronger choice when you need flexible content modeling, multi-channel delivery, real-time collaboration across distributed teams, or a custom editorial interface that matches your specific workflow. For projects built on Next.js or other modern frameworks, Sanity integrates significantly more cleanly than WordPress.

Migrate from Contentful to Sanity: A Complete Developer Guide

Mariusz — Sat, 18 Jul 2026 16:58:00 +0000

Is Contentful Migration the Right Choice for You?

While it has long been a go-to option for teams adopting headless CMS architectures, many organizations have now decided to migrate Contentful to Sanity or other setups.

Companies find Contentful's structure and pricing more and more restrictive as their projects scale.

Limits on content types, rigid field definitions, and the absence of a real pay-as-you-go model often make it difficult to stay flexible without moving into costly enterprise plans.

For teams focused on speed, content variety, and developer experience, these constraints are a major bottleneck. This is why they choose a shift toward more customizable and scalable alternatives like Sanity.

This guide covers two ways of migrating a setup from Contentful to Sanity — the same SEO-safe migration techniques Pagepro uses in its own projects.

Why Teams Migrate from Contentful to Sanity

Contentful Limitations

Contentful's Starter and Lite plans are enough for most small-scale projects. However, once content structures start to grow, so do the constraints. The 25-content-type limit can be a serious obstacle for mid-sized or content-heavy applications. There's no pay-as-you-go option, so scaling up means jumping to a much higher plan instead of paying for incremental usage. Even then, the 50-content-type limit might not be enough in some cases.

On the development side, content models are bound by predefined field types, fixed validations, and a uniform UI that can't be customized for specific workflows. Rich text editing is also rigid. You can remove formatting options from the toolbar, but not extend or tailor the editor to support things like custom blocks, lists, or reference elements.

Why Sanity Is a Better Fit

Sanity addresses these pain points with a developer-first approach. Its schema system offers full control over content types, relationships, and validation rules. PortableText replaces Contentful's static rich text editor with a flexible structure that supports custom components and dynamic content.

Real-time collaboration, customizable editing interfaces, and an API built around GROQ queries make it easier to build, query, and scale complex data models. Combined with a more accommodating pricing structure and strong integration with frameworks like Next.js, Sanity offers the agility that growing teams need without forcing trade-offs.

We recommend Sanity because it gives both developers and content teams real freedom. You can shape the CMS around your product, not the other way around.
— Rafał Dąbrowski, Developer at Pagepro

For a deeper comparison, see Headless CMS Guide: Sanity vs Contentful.

Pricing Comparison

Pricing as of October 2025.

Sanity stands out for its gradual, transparent pricing. It includes a forever-free tier and paid plans starting at around $15 per user/month for the "Growth" tier.

Contentful does offer a free plan as well, but as soon as you require any meaningful team collaboration or commercial usage, the first paid tier jumps to around $300/month (or higher) for the next level up. Additionally, if you cross 25 content types or have more than 10k of data, you might have to buy the Lite Space, which costs $850.

That sharp leap between the free plan and the next level means the decision to "go live" with Contentful comes with a significant budget step that doesn't scale gently. Sanity allows a smoother transition from free to paid, whereas with Contentful, you may face a big budget move early on.

Planning a Safe Migration

Migrating from Contentful to Sanity is a structural change that can impact how your content, SEO, and integrations behave. Before running any scripts, decide which migration strategy makes the most sense for your project and learn about its risks.

Understand the Risks

Feature parity. Sanity may not have direct replacements for every Contentful plugin, so some marketplace extensions might need to be rebuilt or replaced with custom solutions. In many cases, this becomes an opportunity to clean up unused or outdated features. If a plugin supports a critical part of your workflow, plan for a rebuild.

SEO and content integrity risks. Losing URL structures, internal links, or metadata during transfer can cause ranking drops and broken pages. Redirects, sitemaps, and structured data should be verified early in the process.

Data corruption or loss. Complex content models, broken relationships, and rich text formatting can all suffer during conversion, especially with localized data or large asset libraries.

Migration testing should happen at multiple stages: first with automated checks (to confirm record counts, field types, and assets) and then with manual visual reviews to confirm the content looks identical in Sanity Studio and on the frontend.

Choose the Right Migration Path

Once you've assessed the risks, decide how much of the existing structure should carry over. There are two approaches:

Keep your existing structure — a fast and low-risk path where you move the current setup to Sanity without major refactoring. Ideal if your main goal is to reduce costs or overcome Contentful's limitations without redesigning your data model.
Rebuild and migrate — a more strategic option where you use a custom script to redesign your content structure for long-term flexibility. This approach takes more time but gives you complete control over how your CMS evolves.

If you're unsure, start by migrating the current setup using the official tool, confirm stability, and then iterate with schema improvements later. For small to mid-sized projects, this hybrid approach often completes in just a few days, as long as there are no missing dependencies or complex plugin integrations.

Option 1: Migrate Using the Official Contentful-to-Sanity CLI

The fastest way to transfer your content from Contentful to Sanity is to use the official CLI tool, contentful-to-sanity. It exports all your data, converts it into Sanity's format, and even generates matching schema files. You can have a working Sanity Studio in minutes.

Step 1: Get Your Contentful Credentials

You'll need three API keys from your Contentful account:

Space ID — easiest to copy from your project URL (e.g. https://app.contentful.com/spaces/[projectURL]/views/entries) or find it under Settings → Space Settings → General Settings.
Content Delivery API token — create one in Settings → API Keys.
Content Management API (CMA) token — generate it under Account Settings → CMA Tokens, then click the top-right button to create a new personal access token.

Tip: Set your token to expire in 1–30 days. One day is fine for testing, thirty for production.

Step 2: Run the Migration Script

Now that you have your keys, run the CLI command:

npx contentful-to-sanity@latest -s <space-id> -t <cma-token> -a <Content Delivery API - access token> ./output-path

If tokens are correct, you'll see logs of the export. A 401 error means one of the keys is invalid.

After the script finishes, you'll find these files in your output directory:

contentful.json and contentful.published.json — raw exports from Contentful
dataset.ndjson — data formatted for Sanity import
schema.ts — auto-generated schema matching your Contentful models

At this stage, you're about halfway done. The data is ready, and the schema is mapped.

Step 3: Create Your Sanity Project

If you don't already have a Sanity account, sign up at sanity.io. Then create a new, clean project:

npm create sanity@latest \
  --template clean \
  --create-project "Your Project Name" \
  --dataset production \
  --output-path my-sanity-project

Log in when prompted, select "Create new project," choose your organization, and follow the prompts. You should have a clean Sanity project.

Open your sanity.config and sanity.cli files to check your project ID and dataset — you'll need them soon.

Copy the generated schema.ts into your schemaTypes directory with an updated naming, and update your index.ts:

import { types } from "./schema-contentful";
export const schemaTypes = [...types];

That will allow you to add new schemas later without impacting the auto-generated file. Run npm run dev to preview your new Studio. On the left, you'll see all the content types, empty for now. Remember their names before moving on to data migration.

Step 4: Import Your Content

Copy dataset.ndjson into your project and run:

npx sanity dataset import ./dataset.ndjson

Select your dataset (default: production). After the import completes, your entries will appear inside Sanity Studio.

Next, update your fetching methods in the Next.js app to use the new data source.

Step 5: Update Your Queries

Replace your Contentful GraphQL API with Sanity's GROQ-based client:

// Sanity client configuration
const client = createClient({
  projectId: process.env.NEXT_PUBLIC_SANITY_PROJECT_ID || 'your-project-id',
  dataset: process.env.NEXT_PUBLIC_SANITY_DATASET || 'production',
  apiVersion: '2024-01-01',
  useCdn: process.env.NODE_ENV === 'production',
  token: process.env.SANITY_API_TOKEN,
});

Convert your GraphQL queries into GROQ queries. If you're struggling with this part, consider using AI to help.

const PAGE_GROQ_FIELDS = `
_id,
_type,
"slug": slug.current,
internalName,
pageName,
seo {
  _id,
  _type,
  name,
  title,
  description,
  "ogImage": image.asset->url,
  noIndex,
  noFollow
},
topSection[] {
  _id,
  _type,
  _ref,
  internalName,
  // Component CTA
  ...(_type == "componentCta" => {
    headline,
    subline,
    ctaText,
    targetPage-> {
      "slug": slug.current
    },
    urlParameters,
    colorPalette
  }),
  // Component Duplex
  ...(_type == "componentDuplex" => {
    containerLayout,
    headline,
    bodyText,
    ctaText,
    targetPage-> {
      "slug": slug.current
    },
    image {
      asset-> {
        url,
        metadata {
          dimensions
        }
      },
      alt
    },
    imageStyle,
    colorPalette
  }),
`

The -> sign is very important here. When a field is a reference to another document, by default you only get the reference id. To resolve it and get real values, you need to use the -> syntax.

Step 6: Update the Code

After updating the queries, focus on updating the code where you fetch data. Right now, your setup fetches all posts using GraphQL, the Contentful URL, and access tokens:

export async function getAllPosts(isDraftMode: boolean): Promise<any[]> {
  const entries = await fetchGraphQL(
    `query {
      pageCollection(where: { slug_exists: true }, preview: ${
        isDraftMode ? "true" : "false"
      }) {
        items {
          ${POST_GRAPHQL_FIELDS}
        }
      }
    }`,
    isDraftMode,
  );
  return extractPostEntries(entries);
}

Update it to use your new Sanity client and query:

// Get all pages
export async function getAllPosts(isDraftMode: boolean): Promise<any[]> {
  const query = groq`*[_type == "page" && defined(slug.current)] | order(_createdAt desc) {
    ${PAGE_GROQ_FIELDS}
  }`
  const entries = await client.fetch(query)
  return extractPageEntries(entries)
}

Update all the places where you fetch data from Contentful to use Sanity instead. You can still use GraphQL in this scenario — see the official Sanity docs for setup (it requires deploying the API on every schema change).

Step 7: Update the Richtext

Contentful uses its own logic to store and render rich text markdown. Sanity uses its own pattern via the PortableText component.

Define the components for each block type and replace the old Markdown renderer:

import Image from "next/image";
import { PortableText } from "@portabletext/react";
import { PortableTextBlock } from "@portabletext/types";

interface SanityImage {
  _id: string;
  url: string;
  alt?: string;
  caption?: string;
  asset: {
    _ref: string;
    _type: string;
  };
}

interface SanityContent {
  _type: string;
  _key: string;
  children?: Array<{
    _type: string;
    _key: string;
    text: string;
    marks?: string[];
  }>;
  markDefs?: Array<{
    _key: string;
    _type: string;
    href?: string;
  }>;
  asset?: SanityImage;
  url?: string;
  alt?: string;
}

interface PortableTextContent {
  _type: "block" | "image" | "code" | "table" | "list";
  _key: string;
  children?: SanityContent[];
  markDefs?: SanityContent[];
  asset?: SanityImage;
  url?: string;
  alt?: string;
  code?: string;
  language?: string;
}

function SanityImageComponent({ value }: { value: SanityImage }) {
  return (
    <div className="my-6">
      <Image
        src={value.url}
        alt={value.alt || ""}
        width={800}
        height={600}
        className="rounded-lg"
        style={{ width: "100%", height: "auto" }}
      />
      {value.caption && (
        <p className="text-sm text-gray-600 mt-2 text-center italic">
          {value.caption}
        </p>
      )}
    </div>
  );
}

function CodeBlock({ value }: { value: { code: string; language?: string } }) {
  return (
    <pre className="bg-gray-100 p-4 rounded-lg overflow-x-auto my-6">
      <code className={`language-${value.language || "text"}`}>
        {value.code}
      </code>
    </pre>
  );
}

const components = {
  types: {
    image: SanityImageComponent,
    code: CodeBlock,
  },
  marks: {
    link: ({ children, value }: { children: React.ReactNode; value: { href: string } }) => (
      <a
        href={value.href}
        target="_blank"
        rel="noopener noreferrer"
        className="text-blue-600 hover:text-blue-800 underline"
      >
        {children}
      </a>
    ),
    strong: ({ children }: { children: React.ReactNode }) => (
      <strong className="font-bold">{children}</strong>
    ),
    em: ({ children }: { children: React.ReactNode }) => (
      <em className="italic">{children}</em>
    ),
    code: ({ children }: { children: React.ReactNode }) => (
      <code className="bg-gray-100 px-1 py-0.5 rounded text-sm font-mono">
        {children}
      </code>
    ),
  },
  block: {
    h1: ({ children }: { children: React.ReactNode }) => (
      <h1 className="text-3xl font-bold mb-4 mt-8">{children}</h1>
    ),
    h2: ({ children }: { children: React.ReactNode }) => (
      <h2 className="text-2xl font-bold mb-3 mt-6">{children}</h2>
    ),
    h3: ({ children }: { children: React.ReactNode }) => (
      <h3 className="text-xl font-bold mb-2 mt-4">{children}</h3>
    ),
    h4: ({ children }: { children: React.ReactNode }) => (
      <h4 className="text-lg font-bold mb-2 mt-4">{children}</h4>
    ),
    normal: ({ children }: { children: React.ReactNode }) => (
      <p className="mb-4 leading-relaxed">{children}</p>
    ),
    blockquote: ({ children }: { children: React.ReactNode }) => (
      <blockquote className="border-l-4 border-gray-300 pl-4 my-4 italic text-gray-700">
        {children}
      </blockquote>
    ),
  },
  list: {
    bullet: ({ children }: { children: React.ReactNode }) => (
      <ul className="list-disc list-inside mb-4 space-y-1">{children}</ul>
    ),
    number: ({ children }: { children: React.ReactNode }) => (
      <ol className="list-decimal list-inside mb-4 space-y-1">{children}</ol>
    ),
  },
  listItem: {
    bullet: ({ children }: { children: React.ReactNode }) => (
      <li className="ml-4">{children}</li>
    ),
    number: ({ children }: { children: React.ReactNode }) => (
      <li className="ml-4">{children}</li>
    ),
  },
};

export function MarkdownSanity({ content }: { content: PortableTextBlock[] }) {
  return (
    <div className="prose prose-lg max-w-none">
      <PortableText value={content} components={components} />
    </div>
  );
}

Replace all usages of the old Markdown component:

// Before
<div className="prose">
  <Markdown content={post.content} />
</div>

// After
<div className="prose">
  <MarkdownSanity content={post.content} />
</div>

That's enough to transfer the CMS and convert your UI to use Sanity data and rich text. From here, focus on extra features like preview plugins (a must-have for editors) — see the Presentation Tool guide. Also plan out data revalidation using either Webhooks + Revalidate API or the Sanity Live API.

Option 2: Create Your Own CMS Migration Script

If the official CLI tool doesn't work for your project — for example, because you use nonstandard plugins or highly customized content types — you can create your own migration script.

This path takes longer, but it gives you full control over field mapping, schema design, and data validation.

The custom-script path takes longer, but it gives full control. Once your schemas are right, mapping is easy and the output clean and predictable.
— Rafał Dąbrowski, Developer at Pagepro

Step 1: Export Data from Contentful

Install the official CLI:

npm install -g contentful-cli

contentful login

Export your space data:

contentful space export --space-id <your-space-id>

This generates a .json file containing your full space data, including contentTypes, entries, assets, and localization information. For custom migrations, ignore contentTypes and focus on entries.

Each entry's sys object tells you what content type it belongs to, along with its ID and relationships — use this to identify how fields map to your new schema.

Step 2: Define Your Sanity Schemas

In a fresh Sanity project, create schemas that match your data model. Here's an example defining SEO metadata and Page document types:

// ts-nocheck
import { defineField, defineType } from "sanity";

export const seoType = defineType({
  type: "document",
  name: "seo",
  title: "SEO meta tags",
  fields: [
    defineField({
      name: "name",
      type: "string",
      title: "Internal name",
      hidden: false,
      validation: (Rule) => Rule.required(),
    }),
    defineField({
      name: "title",
      type: "string",
      title: "SEO title",
      hidden: false,
      description: "This will override the page title in search engine results",
    }),
    defineField({
      name: "description",
      type: "string",
      title: "Description",
      hidden: false,
      description: "This will be displayed in search engine results",
    }),
    defineField({
      name: "image",
      type: "image",
      title: "Image",
      hidden: false,
    }),
    defineField({
      name: "noIndex",
      type: "boolean",
      title: "Hide page from search engines (noindex)",
      hidden: false,
    }),
    defineField({
      name: "noFollow",
      type: "boolean",
      title: "Exclude links from search rankings (nofollow)",
      hidden: false,
    }),
  ],
});

export const pageType = defineType({
  type: "document",
  name: "page",
  title: "Page",
  description: "Our landing pages",
  fields: [
    defineField({
      name: "title",
      type: "string",
      title: "Title",
      validation: (Rule) => Rule.required(),
    }),
    defineField({
      name: "slug",
      type: "slug",
      title: "Slug",
      validation: (Rule) => Rule.required(),
    }),
    defineField({
      name: "seo",
      type: "reference",
      title: "SEO metadata",
      to: [{ type: "seo" }],
    }),
    defineField({
      name: "content",
      type: "array",
      title: "Content",
      of: [
        { type: "topicBusinessInfo" },
        { type: "topicProduct" },
        { type: "componentProductTable" },
      ],
    }),
  ],
});

import { pageType, seoType } from "./schema.fresh";

export const schemaTypes = [pageType, seoType];

Step 3: Write Your Migration Script

The script maps data from the old system into Sanity schemas and generates an .ndjson file for import. First, read the input file, extract the required data, map it to the new schema, then generate the NDJSON output:

#!/usr/bin/env node

const fs = require('fs');
const path = require('path');

const CONFIG = {
  inputFile: 'contentful-export-8g9vl6174izn-master-2025-10-15T10-17-31.json',
  outputFile: 'pages-migrated.ndjson',
  primaryLocale: 'en-US'
};

let contentfulData;
try {
  const filePath = path.join(__dirname, CONFIG.inputFile);
  console.log(`📖 Reading Contentful export from: ${filePath}`);
  contentfulData = JSON.parse(fs.readFileSync(filePath, 'utf8'));
} catch (error) {
  console.error('❌ Error reading Contentful export file:', error.message);
  process.exit(1);
}

// Filter for page entries
const pageEntries = contentfulData.entries.filter(entry =>
  entry.sys?.contentType?.sys?.id === 'page'
);

console.log(`📄 Found ${pageEntries.length} page entries`);

function convertPageToSanity(contentfulPage) {
  const fields = contentfulPage.fields;
  const primaryLocale = CONFIG.primaryLocale;

  const sanityPage = {
    _type: 'page',
    _id: contentfulPage.sys.id,
    title: fields.pageName?.[primaryLocale] || fields.internalName?.[primaryLocale] || 'Untitled',
    slug: {
      _type: 'slug',
      current: fields.slug?.[primaryLocale] || 'untitled'
    }
  };

  if (fields.seo?.[primaryLocale]) {
    sanityPage.seo = {
      _type: 'reference',
      _ref: fields.seo[primaryLocale].sys.id
    };
  }

  // TODO: Handle content later / add sections etc
  sanityPage.content = [];

  return sanityPage;
}

const sanityPages = pageEntries.map(convertPageToSanity);

const ndjsonContent = sanityPages
  .map(page => JSON.stringify(page))
  .join('\n');

const outputPath = path.join(__dirname, CONFIG.outputFile);
try {
  fs.writeFileSync(outputPath, ndjsonContent);
  console.log(`✅ Migration completed!`);
  console.log(`📄 Converted ${sanityPages.length} pages`);
  console.log(`📁 Output file: ${outputPath}`);
} catch (error) {
  console.error('❌ Error writing output file:', error.message);
  process.exit(1);
}

if (sanityPages.length > 0) {
  console.log('\n📋 Sample converted page:');
  console.log(JSON.stringify(sanityPages[0], null, 2));

  console.log('\n📊 Field mapping summary:');
  console.log('Contentful → Sanity');
  console.log('pageName → title');
  console.log('slug → slug.current');
  console.log('seo → seo (reference)');
}

Once you have a working base, focus on creating and refining your schemas. Getting the schemas right is the most time-consuming — and important — part of this migration. Once that's done, mapping the data is straightforward.

When your output looks correct, import it into Sanity and continue with Step 4 from Option 1: updating rich text rendering and adding any plugins you need.

Some teams use alternative methods, like web scraping, to extract content, if that approach fits their project better.

Conclusion

Migration is a process that rewards preparation. With a clear plan, backups, and a careful approach, anybody can migrate Contentful to Sanity.

How long it takes depends entirely on your goals. If you're simply moving to Sanity for better flexibility and are happy with your current data model, the process can be very quick. But if you're rebuilding schemas or adding new features, treat it as an opportunity to refine your CMS structure for the long term.

Above all, never skip testing. Validate your redirects, metadata, and content relationships before the final switch. A few extra rounds of automated and manual checks can save you from downtime, broken links, and SEO drops.

FAQ

Why Do Companies Migrate Contentful to Sanity?

Teams move from Contentful to Sanity for greater flexibility, customization, and predictable costs. Sanity lets developers define their own content models, add custom input components, and collaborate in real time. It works better for growing teams that need control without the limits of a closed ecosystem.

Why is Contentful So Expensive?

The biggest issue with Contentful's pricing is the steep jump between the free and paid tiers. The free plan is generous for individual developers, but for teams only a few content types and users are allowed. The next available plan costs roughly $300/month, plus additional purchases like different types of spaces.

Is Sanity CMS Free?

Yes. Sanity offers a free forever plan suitable for small projects, MVPs, and personal sites. Paid plans start at around $15 per user/month, adding collaboration features, increased API limits, and additional datasets.

How Long Does it Take to Migrate Contentful to Sanity?

Migration time depends on your setup. Using the official CLI tool, a simple project can be moved in a day or two. For larger projects with custom content models, the process can take a few weeks.

What's the Difference Between Using the CLI Tool and Writing a Custom Script for Migration?

The CLI tool is fast and automated — it exports data from Contentful, converts it into Sanity's format, and generates schema files. Writing a custom migration script takes longer but gives you total control: you can redesign schemas, fine-tune data mapping, and decide exactly how relationships and fields are structured.

Can I Migrate Assets, Such as Images and PDFs, from Contentful to Sanity?

Yes. The official CLI handles assets automatically, while a custom script requires you to include them manually using the assets array and Sanity's upload API.

Best CMS in 2026: Sanity vs WordPress

Mariusz — Fri, 17 Jul 2026 19:21:00 +0000

Sanity and WordPress for Content Management

When building a new website or app, picking a CMS can affect your site's current and future performance. For many teams, the decision comes down to Sanity vs WordPress, and their two very different approaches to content management.

WordPress offers familiarity, a huge plugin ecosystem, and community support. Sanity has a structured, API-first approach, real-time collaboration, and integration with frameworks like Next.js.

Today, we'll compare Sanity and WordPress side by side. This article will cover performance, workflows, costs, ease of use, and security, all to help with choosing the right content management for your project.

Headless CMS vs Traditional CMS

Before comparing Sanity and WordPress directly, we need to understand the difference between headless and traditional CMS platforms.

A traditional CMS like WordPress bundles everything together: content storage, editing interface, design templates, and the frontend that displays your site. With that, launching your site is very easy. However, since your content is coupled to one presentation layer (the website), delivering the same content to an app or a digital display can be tricky.

A headless CMS separates content management from presentation. Content is stored in a structured way and delivered via APIs, so developers can connect it to any frontend. It allows for more control, but requires expert knowledge for setup and maintenance.

Overview of Sanity and WordPress

What is Sanity CMS?

Sanity is a headless content operating system launched in 2017. Unlike WordPress, which is monolithic, Sanity separates content from presentation, letting you deliver content to any frontend via APIs. It's built for developers who want structured content models, modern workflows, and easy collaboration in content editing.

Who Owns Sanity CMS?

Sanity was founded in Oslo, Norway, by Even Westvang, Simen Svale Skogsrud, and Magnus Hillestad. The company, Sanity.io, continues to maintain and develop the platform, which has attracted global clients and investors, including notable brands like Puma, Morning Brew, Cloudflare, and AT&T.

Use Cases of Sanity

Sanity is often chosen when teams need a developer-first CMS that's easy to scale, but it also has its uses for:

Content-rich websites and apps.
E-commerce solutions.
Multi-channel publishing.
Enterprise content hubs.
Design-driven websites.

What is WordPress?

WordPress is a traditional CMS that allows you to create, publish, and manage websites without building everything from scratch. It powers more than 40% of all websites worldwide and holds around 60% of the CMS market share. Its popularity comes from accessibility: with over tens of thousands of free themes and 65,000+ plugins, it offers options to extend features and get a website up and running quickly.

Who Developed WordPress?

WordPress was created by Matt Mullenweg and Mike Little in 2003 as a fork of a blogging tool called b2/cafelog. Today, it is an open-source project maintained by a large community of contributors and backed commercially by Automattic.

Use Cases of WordPress

WordPress is used for everything from personal blogs to enterprise websites, and its most common uses include:

Blogging and publishing.
Business sites.
Online stores.
Membership and community sites.
Enterprise websites.

What is the Difference Between Sanity vs WordPress for Developers?

Choosing between Sanity and WordPress depends on how you want to build and scale your site over time. Here's how the two compare across the areas that matter most.

Feature	WordPress	Sanity
Content Modeling	Pages, posts, custom post types; rigid for advanced needs	Schema-based, structured, reusable content
Pricing	Free core; costs for hosting, themes, plugins, or VIP	Free tier; usage-based pricing as projects grow
Performance	Depends on hosting, caching, and plugins	API-first; fast with frameworks like Next.js
Integrations	59k+ plugins and 11k+ themes	API-driven; integrates with Vercel, Shopify, Algolia
DevEx & UX	Easy for beginners; limited flexibility for devs	Developer-first; code-defined models, customizable Studio
Workflows	Basic publishing; advanced workflows need plugins	Real-time collaboration, versioning, structured flows
Security	Relies on hosting and plugin updates; vulnerable if outdated	Managed backend; API-based security, smaller attack surface
Hosting	Requires separate hosting (shared, managed, or VIP)	CMS is fully managed; only host the frontend

Content Modeling

WordPress: Since it's a traditional CMS, it uses the classic model of pages and posts. It allows for the customization of post types, fields, or plugins. However, its structure is relatively rigid, which can lead to complex workarounds for more advanced needs.

Sanity: Its structure is built around schemas, which are sets of rules defining how your content is structured. You can specify exactly what types of content you need, and Sanity enforces that structure. Reusing content across different platforms becomes much easier.

Pricing

WordPress: The core CMS is free and open source. You still need to factor in hosting, premium themes, and paid plugins. The final costs can vary widely depending on whether you run a small site on shared hosting or an enterprise setup on WordPress VIP.

Sanity: Has a free plan with limited API requests and users, plus paid plans that scale based on usage (API calls, storage, seats). It can be cost-effective for small projects, but as your traffic or content needs grow, so do the costs.

Performance

WordPress: Runs on PHP and MySQL. Its performance depends heavily on hosting quality, caching plugins, and CDN setup. The right configuration can handle large traffic, but out of the box, WordPress is less optimized.

Sanity: Headless by design, it serves content via APIs. When paired with modern frameworks like Next.js, sites can be pre-rendered for fast load times and excellent Core Web Vitals. Scaling is handled by Sanity's managed infrastructure, so heavy traffic is less of a problem.

Integrations

WordPress: Famous for its plugin ecosystem, and for good reason. WordPress offers thousands of plugins and themes, and you can add SEO tools, payment gateways, and more without custom coding.

Sanity: Its flexibility comes from APIs, not prebuilt add-ons. Doesn't use plugins in the same way. Instead, it integrates with developer tools and modern platforms like Vercel, Shopify, or Algolia.

DevEx & UX

WordPress: Non-developers find WordPress easy to pick up, thanks to a visual dashboard, WYSIWYG editing, and prebuilt templates. Developers, however, might find customizing beyond themes and plugins cumbersome.

Sanity: Geared towards developers. Content models are code-first, and frontends are built with frameworks like React and Next.js. For editors, Sanity Studio offers a smooth experience and a customizable UI. Its initial setup does require some technical expertise.

Workflows

WordPress: Content creation is pretty straightforward, but advanced workflows (approval chains, editorial review, versioning) often require extra plugins. Collaboration features are limited compared to modern tools.

Sanity: Focuses a lot on the workflows. Real-time collaboration, version history, and structured editing make it a great choice for larger teams.

Security

WordPress: The security of your WordPress site depends largely on hosting and regular updates. Vulnerabilities often come from outdated plugins.

Sanity: Security is centralized rather than plugin-driven. Its headless architecture reduces the attack surface since the CMS doesn't directly serve the website. Content is delivered through secure APIs, and infrastructure is managed by Sanity.

Hosting

WordPress: Requires hosting to run. Since its performance and security can vary depending on your provider, enterprise users often opt for WordPress VIP.

Sanity: A fully managed, cloud-based platform, letting you scale as you please. You don't need to worry about hosting the CMS itself; you only host your frontend (e.g., on Vercel or Netlify).

Sanity: Pros and Cons

What Are the Benefits of Using Sanity?

Sanity stands out from other CMS options as a modern, headless CMS built for flexibility and performance. Its main advantages include:

Flexible content modeling. Define custom schemas to structure your content just the way your project requires.
Real-time collaboration. Multiple team members can edit content at the same time in Sanity Studio, with updates appearing instantly.
Developer-first approach. Sanity allows a seamless integration with third-party tools.
Customizable editor. You can tailor the editing environment to match your content needs.
Performant and scalable. Content is delivered through Sanity's managed Content Lake, optimized for speed and large-scale usage.
Reusable content. Write once, publish anywhere: websites, mobile apps, IoT, or digital displays.

What are the Cons of Sanity CMS?

Teams without technical resources can find some aspects of Sanity challenging:

Steep learning curve. Setting up schemas and connecting a frontend requires coding knowledge, unlike WordPress's plug-and-play approach.
No traditional themes or plugins. You can't just install a theme or plugin to get started. You'll need a developer to build and integrate the feature you want.
Scaling costs. Sanity's free plan is a great value for small projects, but heavy API usage, large datasets, or many team members can increase monthly costs.
Hosting split. While Sanity hosts the CMS, you must host your frontend separately (e.g., on Vercel or Netlify), which adds an extra step for setup.
Smaller ecosystem. Sanity has strong community support, but its ecosystem of third-party integrations is much smaller compared to WordPress.

WordPress: Pros and Cons

What Are the Benefits of Using WordPress?

WordPress is one of the most popular content management solutions for modern web development for several reasons:

Free and open-source CMS. Anyone can install and use WordPress at no cost, making it accessible for individuals and businesses.
Huge plugin ecosystem. With nearly 60,000 plugins, you can add features like SEO optimization, e-commerce (WooCommerce), contact forms, and analytics to your site without custom code.
Thousands of themes. Free and premium WordPress themes allow you to get your website running quickly with no experience needed.
Ease of use. The dashboard and WYSIWYG editor make content management approachable even for non-developers.
Community support. WordPress has a massive global community that shares tutorials and support, lowering the barrier for learning.
Scalability. With the right hosting and setup, WordPress can handle all types of websites, personal blogs, and high-traffic enterprise sites alike.

Disadvantages of a WordPress Site

While WordPress offers plenty of strengths, it also comes with limitations and risks:

Performance issues. Out of the box, WordPress might be slow. Performance metrics often rely on caching plugins, CDNs, and optimized hosting.
Security vulnerabilities. Its popularity makes it a frequent target for hackers. Many breaches come from outdated themes or plugins.
Plugin dependence. Extending functionality often means installing multiple plugins, which can lead to compatibility issues and heavier sites.
Maintenance overhead. Regular updates for plugins, themes, and WordPress core are necessary to keep a site secure and stable.
Limited content modeling. The post/page/custom post type structure is less flexible compared to modern headless CMS platforms.
Design limitations without coding. While themes help, customizing them deeply often requires PHP, HTML, or CSS knowledge.

When to Choose Sanity vs WordPress

Use Case	Choose Sanity if…	Choose WordPress if…
Project Type	Multi-channel platforms, apps, and scalable sites	Blogs, portfolios, small business sites
Content Needs	Structured content, reusable across channels	Simple pages and posts managed in one place
Team	Developer-led teams who can define schemas and build frontends	Non-technical teams managing content via dashboard
Performance	High performance, Core Web Vitals, and scalability are priorities	"Good enough" performance with plugins and decent hosting
Setup	You're okay with a steeper setup for long-term flexibility	You need a fast, out-of-the-box setup with themes/plugins
Budget	Prepared for usage-based pricing as you scale	Relying on free core + low-cost hosting and plugins
Future Goals	Long-term growth, custom experiences, future-proof architecture	Quick launch, affordable maintenance, and community support

Sanity works best for projects that need flexibility and plan to scale in the future, though it requires some technical expertise. A structured content model, headless architecture, and integrations with frameworks like Next.js make it a great choice for high performance and developer-driven workflows.

WordPress is a practical choice for blogs, small businesses, and content-focused sites where ease of use matters more than technical flexibility. Free at its core with affordable hosting, WordPress allows for a quick site launch, thanks to the numerous themes and plugins. Non-technical teams can manage sites through their dashboard, with add-ons like WooCommerce or Yoast extending core functionality.

WordPress and Sanity: Which CMS is Best for You?

So, which one is the best CMS? Both Sanity and WordPress are powerful platforms, but they serve different needs.

WordPress is a tried-and-true choice for quick setup, affordability, and ease of use, especially for smaller websites, blogs, or businesses that rely on plugins to extend functionality.

Sanity, by contrast, offers a modern, developer-first approach and performance built for the future of the web.

Already on WordPress but feel limited by its performance or extensive plugin setup? Pagepro specializes in helping teams migrate from WordPress to modern stacks like Sanity and Next.js to provide the best performance.

FAQ

Is Sanity Free or Paid?

Sanity offers both options. It has a free plan with generous limits on users, content, and API calls. For larger projects, users can purchase usage-based paid plans that scale with their traffic, storage, and team needs.

Is WordPress Still The Most Popular CMS?

Yes. As of 2025, WordPress powers about 43% of all websites and holds over 60% of the CMS market share. Its huge ecosystem of plugins, themes, and community support keeps it the most widely adopted CMS in the world.

Which CMS Is Better Than WordPress?

It depends on your needs. WordPress is quick to set up and affordable, making it the favorite of blogs, small businesses, and content-driven sites. Headless CMS platforms like Sanity, Contentful, or Strapi can be better for projects that need multi-channel publishing and modern developer workflows.

Is Sanity Better Than WordPress?

Sanity is better if you need flexibility and developer-first workflows. It also holds a 4.7/5 rating on G2, compared to WordPress's 4.4/5.

WordPress is better if you want simplicity and speed. It's free at its core, easy for non-technical users, and backed by a massive plugin ecosystem.

Can You Self-Host Sanity CMS?

Sanity Studio is self-hostable, which means you can customize and deploy the editing environment on your own servers or domain. However, its backend, Sanity Content Lake, where all your content is stored and delivered, cannot be self-hosted.

Is Sanity Open-Source?

Sanity is a proprietary platform, but some of its parts are open source. The Sanity Studio framework is open source and customizable, and the core content infrastructure (Sanity Content Lake) is hosted and managed by Sanity.io.

Sanity vs Contentful 2026: Which Headless CMS Wins?

Mariusz — Sun, 12 Jul 2026 22:00:00 +0000

TL;DR

Sanity and Contentful are modern CMS platforms that allow teams to manage content separately from the frontend application.
Sanity offers a highly customizable content studio and flexible schema design, giving developers greater control over content structures and editorial workflows.
Contentful provides a more standardized SaaS CMS environment with ready-to-use infrastructure and tools designed for enterprise content management.
Both platforms integrate easily with modern frontend frameworks and APIs, making them suitable for headless architectures and multi-channel content delivery.
The choice between Sanity and Contentful often depends on factors such as customization needs, team workflows, scalability requirements, and pricing models.
Understanding the differences between these CMS platforms helps teams choose the solution that best supports their content strategy and development stack.

How to Pick the Right CMS in 2025?

When it comes to content solutions, two of the most popular picks in 2025 are Sanity vs Contentful. Both are headless, API-driven platforms, but they differ in flexibility, pricing, and how much control they give you.

Picking the right CMS solution starts with knowing your team's needs. There is a difference in how developers want to work and the kind of editing experience content teams expect. At the same time, you have to consider how the future platform might scale with your website, and if it's within budget.

For those trying to choose between Contentful and Sanity, we've prepared a quick comparison of both. Let's find out which is the better choice for you.

Features of Contentful vs Sanity

Feature	Sanity	Contentful
Type	Content Operating System offering schema-as-code flexibility and real-time content collaboration.	A headless CMS with a structured, UI-first approach.
G2 Rating	4.7/5	4.2/5
Developer Experience	Sequential editorial workflows with a clear structure.	Models created via UI or migration scripts. Less flexibility but faster setup for non-technical teams.
Collaborative Editing	Real-time edits and live updates.	Studio is fully customizable via React and the structure builder.
Querying & API	GROQ (proprietary and highly flexible) plus REST and GraphQL.	Supports REST and GraphQL.
Customization & UI	Studio is fully customizable via React and structure builder.	Limited UI customization. Offers an App Framework.
Performance	Optimized for low-latency, real-time updates. Uses distributed Content Lake, with optional CDN layer.	Enterprise-grade performance with global CDN, 99.99% uptime SLA, handles massive API volumes.
Ecosystem	Open-source ecosystem with strong developer engagement.	Marketplace with a large partner network and extensive integrations.
Pricing Model	Usage-based pricing, flexible for smaller projects.	Fixed-tier pricing that may become costly with scale.
Best For	Developer-led teams seeking flexibility, real-time content workflows, and custom UIs.	Teams needing structure, enterprise governance, and predictable scaling.
Use Cases	PUMA, Morning Brew, Cloudflare	KFC, BMW, Notion

Sanity: Content Operating System

As a Content Operating System, Sanity gives developers complete control over how content is structured, edited, and delivered. Unlike CMSs with rigid, UI-driven models, Sanity stores content as structured data defined entirely in code. The content model can evolve alongside the product without fighting platform limitations, and it works seamlessly with frontend solutions like Next.js.

Many frontend developers like that Sanity's schema-as-code fits right into their version control workflow, so content model changes are tracked and reviewed just like any other part of the codebase.
— Rafał Dąbrowski, Pagepro Developer

Sanity is the leader in the headless CMS industry. It's aimed at teams that want real-time collaboration and the ability to tailor the editing environment to their needs.

Sanity Core Features

Schema-as-code which lets you define your entire content structure in JavaScript or TypeScript.
Sanity Studio, a highly customizable, open-source editing environment built with React.
Real-time editing for multiple users. They can edit the same document simultaneously, with changes synced instantly.
Content Lake, a cloud-hosted datastore that delivers content updates in milliseconds.
GROQ query language with a powerful, flexible syntax for fetching exactly the data you need.
Build or install plugins for workflows, integrations, and custom field types.
Built-in image CDN with automatic transformations and optimization.

The Pros of Sanity

Flexibility — Because the schema is defined in code, developers can model and manage content exactly as they need it without working around a UI's constraints.

Real-Time Collaboration — Editors see changes instantly, making it easier to work without overwriting.

Fully Customizable Studio — You can adapt the editing interface to match the project's needs and add custom input components.

Version Control for Content Models — Since schemas live in your codebase, they can be tracked, reviewed, and deployed like any other part of the application.

Performance — Content Lake delivers low-latency data and supports live updates to the front end.

Plugin Ecosystem — Growing library of official and community plugins for analytics, localization, e-commerce, and workflow enhancements.

Generous Free Tier — Suitable for prototypes or small sites before scaling up to paid usage.

The Cons of Sanity

Steeper Setup for Non-Developers — Without a developer to define schemas, the content platform has no ready-to-use structure.

Learning Curve for GROQ — While powerful, Sanity's proprietary query language isn't as widely known as GraphQL, so teams need time to get up to speed.

Usage-Based Pricing — Costs can spike if you have high traffic, many API requests, or large amounts of stored data.

Fewer Turnkey Integrations — While the plugin ecosystem is growing, it's smaller than Contentful's established marketplace.

What is Sanity.io Used For?

Sanity is widely used for projects where content complexity and flexibility are essential:

Multi-platform content delivery to push content to websites, apps, and in-store displays from a single source.
Custom editorial workflows matching a brand's content process.
Sites that need collaborative publishing, live dashboards, or apps where content changes need to appear instantly.
Design- and content-rich sites that need a CMS to adapt to unique layouts or structures.

Well-known brands like PUMA, Morning Brew, and Cloudflare have used Sanity for projects that require both creative freedom and scalable performance.

Contentful: Headless CMS

Contentful is a cloud-native, API-first headless CMS, sometimes referred to as a "composable content platform." It decouples content storage from presentation, offering content as JSON data via REST or GraphQL APIs.

This architecture makes it flexible and channel-agnostic, ideal for modern omnichannel publishing.

Contentful Core Features

API-first architecture with REST and GraphQL endpoints for content delivery.
Structured content modelling for defining content types, fields, and relationships.
Role-based permissions for editorial governance.
Content versioning with history and rollback.
App Framework and Marketplace for integrations with analytics, e-commerce, translation, and marketing tools.
Global CDN for fast content delivery worldwide.

The Pros of Contentful

Contentful has become a go-to choice for many enterprises because it blends the stability of a mature platform with the flexibility of a headless setup. Its features are built to support large teams and high-traffic projects.

Reliability — Known for uptime and stability, backed by SLAs and global CDN infrastructure.

Predictable Workflows — A structured, UI-driven content model is easy for non-technical editors and marketers to follow, reducing errors in large teams.

Integrated Ecosystem — The App Marketplace and strong partner network make it straightforward to connect with third-party services.

Omnichannel — The API-first approach lets you push the same content to multiple platforms easily.

The Cons of Contentful

Contentful is a great option if you're looking for reliability and governance, but it has some significant trade-offs:

Rigid Content Modelling — The structured approach is great for governance but can feel inflexible when requirements change. Introducing a new nested relationship or restructuring content types often requires multiple migration scripts and extensive testing.

Limited Previews — Contentful offers a Preview API and a Live Preview SDK, but they require extra setup. Without them, editors can't see draft changes instantly, so feedback loops are slower compared to CMSs with built-in real-time preview.

Workflow Gaps — There's no built-in real-time collaborative editing (like Google Docs or Sanity's live editing). Two people editing the same entry risk overwriting each other's changes.

API Rate Limits — Build processes, especially in static site generators or large migrations, can hit rate limits. On busy projects, this can cause delays unless you move to a higher-cost plan.

High Scaling Costs — Pricing is tiered by users, locales, and content types. A project might start affordably but become expensive as you add editorial staff, expand into multiple regions, or store more entries.

Learning Curve — While editors can pick up the UI quickly, developers must learn Contentful's specific APIs, content modelling patterns, and migration tooling, which adds onboarding time.

Which Companies Use Contentful?

Contentful is often chosen for projects where structured governance, scalability, and predictable workflows are more important than extreme flexibility. Examples include:

Enterprise-scale websites that need strict content structures and localization.
Multi-channel publishing to deliver consistent content across websites, mobile apps, kiosks, and other digital touchpoints.
Marketing and campaign sites where content needs to be updated quickly without involving developers.
Global brand platforms maintaining brand consistency across regions with role-based permissions and approval workflows.

High-profile organisations, like KFC, BMW, and Notion, rely on Contentful for enterprise-scale and multi-platform content delivery. However, many teams are migrating from Contentful due to its high costs and rigid architecture.

What is the Difference Between Contentful and Sanity?

Both Contentful and Sanity are API-first, headless platforms. However, they approach content management very differently.

Contentful takes a UI-first, structured approach. You model content types within its dashboard, define fields through the interface, and let non-technical editors work within a predictable, governed environment. This way, onboarding is much easier for large teams and helps to keep content consistent across regions and channels.

Sanity, on the other hand, is schema-as-code from the ground up. Content models live in the codebase, so developers have complete control over the structure. The Studio editing environment is open-source and fully configurable. The real-time collaboration feature means multiple editors can work on the same content simultaneously without conflicts.

The result is that Contentful often appeals to enterprises that need predictability and a ready-made editorial interface. Sanity is well-liked by developer and editorial teams looking for flexibility.

Sanity vs Contentful Pricing

Pricing as of August 2025.

What's the Cost of Sanity?

Free tier — up to 20 user seats, 2 roles, 2 public datasets, unlimited content types/locales, real-time collaboration, basic compute/API/asset limits. Generous enough for prototypes, internal tools, or small sites.

Growth: $15/seat/month — up to 50 seats, 5 roles, private/public datasets, comments/tasks/content releases, AI Assist features, higher API/bandwidth/asset limits (overages billed separately).

Enterprise: Custom pricing — unlimited seats, advanced access control and governance, SSO, SLAs, dedicated support/onboarding/training, media library add-ons.

How Much Does Contentful Cost?

Free tier — 10 users, 2 roles, 2 locales, 100K API calls/month, 50 GB/month CDN bandwidth, 1 Starter Space. Suitable for learning, prototyping, or very small sites.

Lite: $300/month — 20 users, 3 roles, 3 locales, 1M API calls/month, 100 GB/month CDN bandwidth, comments & task management, scheduled publishing, live collaboration, 1 Starter Space (with option to add 1 Lite Space).

Premium: Custom pricing — everything in Lite plus custom users/roles/locales, unlimited API calls, custom CDN bandwidth, enhanced governance/compliance/security, up to 99.99% uptime SLA, dedicated customer success and 24/7 support, unlimited Spaces and advanced features.

Pricing Comparison Table

Plan	Sanity	Contentful
Free	20 seats, 2 roles, 2 public datasets, unlimited content types/locales, real-time collaboration	10 users, 2 roles, 2 locales, 100K API calls/mo, 50 GB CDN, 1 Starter Space
Mid-Tier	$15/seat/mo, up to 50 seats, 5 roles, private/public datasets, comments, tasks, content releases, AI Assist, usage-based overages	$300/mo, 20 users, 3 roles, 3 locales, 1M API calls/mo, 100 GB CDN, comments, scheduled publishing, live collaboration
Enterprise	Custom pricing, unlimited seats, advanced access control, SSO, SLAs, dedicated onboarding/support, media library add-ons	Custom pricing, unlimited API calls, custom bandwidth, unlimited Spaces, advanced governance, 24/7 support, up to 99.99% SLA
Pricing Model	Seat-based pricing + usage-based add-ons	Fixed-tier pricing with defined limits
Best For	Flexible scaling, custom workflows, collaborative editing	Predictable budgets, strict governance, enterprise-scale delivery

Monthly Costs of Sanity vs Contentful

The difference in costs between Contentful and Sanity, depending on your needs, can be significant. Pagepro's clients usually need at least 5 users and 30 different content types. Here's how a setup like this compares:

Sanity (Growth Tier): 5 users × $15 = $75/month, plus roughly $25 for extra usage → around $100/month.

Contentful (Lite Tier): The free Starter Space covers 25 content types. Going beyond that requires the Lite Space (up to 50 content types), added on top of the Lite Plan: $300 Lite Plan + $850 Lite Space = $1,150/month.

For a 5-user, 30-content-type setup, that's a monthly difference of over $1,000 — switching from Contentful to Sanity could save roughly $12,000 a year.

Sanity vs Contentful: Choosing the Right Option

Both Sanity and Contentful are capable, modern platforms; the better choice comes down to your team's needs.

Pick Sanity if…

Full control over content structure through schema-as-code is important.
Real-time collaboration between editors is a core requirement.
A fully customizable editing environment is needed to match unique workflows.
Flexible, usage-based pricing is preferred for smaller projects with room to scale.
The content model is complex or expected to change frequently.

Choose Contentful if…

A ready-to-use, structured editorial environment will speed up adoption for non-technical users.
Predictable pricing and defined limits outweigh the need for deep customization.
Large, distributed teams rely on strict governance, roles, and approval workflows.
Enterprise-grade reliability, global content delivery, and strong SLAs are top priorities.
A wide ecosystem of integrations and proven enterprise deployments is essential.

In short, Sanity shines when flexibility, customization, and live collaboration matter most, while Contentful excels in structured governance, predictable workflows, and enterprise scalability.

FAQ

What Kind of CMS is Contentful?

Contentful is a headless CMS. It stores content in a structured way and delivers it through APIs, allowing developers to use any technology to display that content on websites, apps, or other digital platforms.

Which CMS is Better, Sanity or Contentful?

Sanity is ideal for developer-led projects that need flexibility, real-time collaboration, and a fully customizable editing experience. Contentful works best for larger teams that value a ready-to-use interface, structured governance, and predictable pricing. Both are powerful headless CMS platforms, but the right one comes down to workflow preferences, budget, and long-term scalability.

What is a Headless CMS?

A headless CMS separates the content management back end from the front-end presentation. Content is created and stored in the CMS, then delivered via an API to any channel.

Is Sanity a CMS?

Sanity is a Content Operating System. It offers more customization, real-time collaboration, and schema-as-code content modeling than traditional CMS options.

What's the Difference Between Headless CMS and Content Operating System?

A headless CMS solution focuses on storing and delivering content via APIs. A Content Operating System, like Sanity, does that too but adds deeper customization, real-time collaboration, and the ability to fully control the content model and editing environment.

Is Sanity CMS Open-Source?

Sanity Studio, the editing interface, is open source and can be customized or extended by developers. The hosted Content Lake (where your content is stored and delivered) is not open source.

Why is Contentful So Expensive?

Contentful can become costly because pricing increases with the number of users, locales, API calls, and content spaces. Enterprise plans also include advanced features, SLAs, and dedicated support, which add to the price.

Strategy for a Successful Legacy System Migration to Next.js

Mariusz — Fri, 10 Jul 2026 18:08:00 +0000

Strategy for a Successful Legacy System Migration to Next.js

By Joanna Chmiel | December 4, 2025

Is Replacing a Legacy System with Next.js Worth It?

Many companies reach a point where the legacy software slows the team down more than it helps. Deployments take too long, small changes feel risky, and the system keeps getting harder to maintain. A legacy system migration to Next.js can improve performance, strengthen security, and give your team room to move faster, but the decision has to line up with your business needs.

That's why this guide walks through the types of legacy system modernization, how to choose the right migration approach, and what a successful migration actually involves.

Before we get into the details, let's get clear on what legacy system migration means.

What Is Legacy System Migration?

Legacy system migration is the process of moving an application or software from outdated technology to a modern platform. Modern businesses migrate legacy systems to improve performance, enable new workflows, strengthen security, reduce maintenance costs, and support digital transformation.

Why Migrate from Outdated Software?

Moving off a legacy system does more than update your tech stack. Done right, it solves three core problems:

Risk reduction – Outdated systems are full of security vulnerabilities. They create compliance risks. They put you one incident away from data loss. Modern technology fixes these problems at the foundation.
Cost optimization – The maintenance costs alone make legacy systems expensive. Add in outdated legacy infrastructure and the developer overhead of working with old code, and modern alternatives start looking cheap.
Future-proofing – Want to do cloud migration? Need seamless integration with new platforms? Modern systems give you better compatibility, easier workflows, and improved team productivity without the constant workarounds.

How Much Does A Legacy System Cost?

Legacy environments rarely show up as a single line item in your budget, which is exactly why they're so expensive. The real cost hides in operational drag that compounds every year.

A Workday study found that a majority of IT budgets go toward simply keeping existing systems running, leaving only a small share for innovation. Many financial services CTOs say their legacy tech stack is too costly for modern applications, and a similar share of business leaders blame legacy systems for a lack of agility.

What Drives Legacy System Costs?

When you analyze the total cost of maintaining legacy systems, you'll notice maintenance work scattered across multiple teams and licensing costs that keep climbing. Infrastructure overhead from outdated technology eats into your budget, while slow release cycles happen because of fragile legacy code that nobody wants to touch. You're constantly applying security patches and compliance updates to stay current.

These expenses don't show up as "legacy system costs" in your budget. But together, they kill velocity, increase risk, and make modernization harder.

How Modernization Reduces Costs

Moving away from legacy platforms changes the economics. You replace unpredictable costs with stable infrastructure and unlock capabilities that old systems can't deliver.

Modern platforms give you cloud-native scaling and cloud migration flexibility without the architectural gymnastics. They're built for stronger security and easier compliance from the ground up. On the development side, content workflows speed up (especially with platforms like Sanity), performance and SEO improve, and your developer experience gets better, which means faster delivery in general.

If your team is running on WordPress, Gatsby, or a custom stack that's slowing you down, Nexity is the fastest path to a modern Next.js + Sanity foundation. Pagepro's migration system delivers in 4 weeks — without touching your product roadmap or putting your search rankings at risk. Learn more about Nexity →

Why Migrate to Next.js?

Migrating to Next.js gives you a modern foundation built for speed, security, and scalability. Teams moving off legacy frontends or older React apps typically see immediate improvements: faster load times, better Core Web Vitals, stronger SEO performance, and fewer infrastructure headaches.

It also simplifies your stack. Backend logic, frontend UI, and API routes live in one framework instead of being scattered across multiple tools. For organizations modernizing their architecture, Next.js is one of the most reliable ways to future-proof your frontend without business disruptions.

Types of Legacy Migrations

Modernization looks different depending on what you're trying to fix. Here are the three most common approaches:

Migration Type	When to Use It	Typical Outcomes
Frontend Migration (to Next.js)	Legacy UI, poor performance, SEO issues	Faster load times, better Core Web Vitals, predictable architecture
CMS Migration (to Sanity)	Content bottlenecks, poor editorial workflow	Structured content, real-time collaboration, scalable content model
Full Legacy Modernization	Outdated database, monolith, fragile logic	Cloud-ready architecture, improved security, easier maintenance

Frontend Migration

Example: Migrating from a legacy application to Next.js.

This makes sense when performance, SEO, or developer experience has gotten painful. You'll typically see faster page loads, better Core Web Vitals scores, and more predictable architecture. Server-first data handling reduces client-side complexity, and your team stops fighting the framework.

CMS Migration

Example: Moving from WordPress or Contentful to Sanity.

When editors struggle with workflow friction, or your content model can't support what you're building, this type of migration might be what you need. If you need API-first architecture for multi-channel delivery, modern platforms like Sanity give you structured content, real-time collaboration, and flexible APIs that work seamlessly with frameworks like Next.js.

Full Legacy System Modernization

A full transfer is the best idea for systems running on outdated databases, monolithic or on-premises architectures, or fragile business logic nobody wants to touch. Full modernization usually means new hosting infrastructure, updated data flows, and consolidating fragmented services into something maintainable.

Plan Your Next.js Migration Strategy

Start With Clear Project Requirements

Before writing any code, consider your modernization strategy. Write down what the project does now and what you need it to do after migration. Cover the basics:

Which pages and routes exist, where data comes from, and what integrations are running?
How the UI should look, what SEO can't break?
Where are you planning to host it?
What performance targets are you aiming for?

This document becomes your reference point for every decision you make during the process and will help you avoid disruptions.

Understand the Existing Routing Structure

Next.js uses file-system-based routing, which might work differently from whatever you're using now.

Create a mapping that shows how your current routes translate to Next.js. Note which pages are static, which routes are dynamic, where you have optional or catch-all paths, how your nested routes work, which routes need protection, and where redirects are required.

Common Issues

Converting routes trips people up in predictable ways. React Router query params become searchParams. Protected routes need to move into middleware. You'll swap useNavigate() for useRouter().push(). And if you're using the App Router, you'll need to rethink how route-based layouts work.

Getting this mapping done upfront saves you from debugging routing issues a few weeks into moving the existing legacy system to a modern one.

Document All External Integrations

Make a list of everything your app talks to:

Analytics platforms like GA, PostHog, or Mixpanel
Authentication providers like Auth0, Firebase, or custom OAuth setups
Payment gateways like Stripe or PayPal
CRM tools and marketing pixels
Headless CMS platforms like Sanity, Strapi, or Contentful

Tip: For each tool, figure out where it'll live in Next.js. Are they server components, API routes, or middleware? It's best done before the migration, so you don't accidentally break something critical halfway through.

Evaluate Your Current Data Sources

There are multiple ways to fetch data with Next.js: Server Components with fetch(), API Route Handlers in app/api/*, Static Site Generation (SSG), Incremental Static Regeneration (ISR), and Server Actions.

The questions you should ask yourself are straightforward: Does this data belong in a Server Component or Client Component? Should you fetch it at build time or request time? Can you cache it with ISR for better performance? And can you eliminate client-side fetching?

Tip: Many apps can eliminate entire useEffect blocks by moving data fetching to the server.

Review the Design

Whether or not you're redesigning, you need to audit what you're working with.

If you're keeping the current design, go through every page and document all sections, modals, forms, and UI states. You need a complete inventory before you start rebuilding.

If you're redesigning during migration, review the new designs carefully. Look for gaps, inconsistencies, or missing states. Ask questions now, since it's easier to catch issues in Figma than in code.

Regardless of your migration strategy, be sure to document these elements:

Buttons and their variants
Forms and validation states
Modals and overlays
Cards and content blocks
Hero sections, CTAs, and major page sections
Animations and scroll effects
Error states (404, 500, loading states)
Responsive behavior across breakpoints

Tip: Audit your UI components to find what's reusable. Identify common layouts and patterns. While you're at it, check the existing theme configuration to learn which design tokens, colors, and spacing systems are already defined.

Audit Layout Variants

Most projects use different layouts for different parts of the site. Map out what you have: global layouts that wrap everything, nested layouts for specific sections, dashboard or admin layouts, marketing page layouts, and authentication layouts.

Tip: Next.js makes this step easier than most frontends. The App Router lets you define layouts once and reuse them across routes without duplicating code.

Optional: Prepare TypeScript Migration

If your old project wasn't in TypeScript, you can add it now. Plan for incremental conversion, so you don't have to type everything on day one. You can set up TS configs in your Next.js project, create shared types for API responses, type your server components, and add types to route handlers as you build them.

Choose the Hosting Platform

Your hosting choice determines which performance optimizations you can use, how your caching works, what your deployment pipeline looks like, and what your infrastructure costs will be.

Next.js works best on Vercel. It's built by the same team, so you get zero-config deployment and full support for every Next.js feature out of the box. Edge rendering, Incremental Static Regeneration, image optimization, and middleware all work without extra configuration.
If you're deploying to AWS, GCP, or Azure, you'll need to handle more setup yourself. You can use containers, serverless functions, or static hosting depending on your infrastructure, but some Next.js features require custom configuration or won't work at all without additional services.
Netlify is another solid option with good Next.js support, though it handles certain features differently than Vercel, particularly around ISR and edge functions.

Hosting Option	Pros	Cons
Vercel	Native Next.js support, zero-config, edge features	Higher cost at scale
AWS/GCP/Azure	Flexible, enterprise-ready	More setup, complex configuration
Netlify	Simple workflow, good support	ISR/edge behaviour differs from Vercel

Tip: Picking the wrong platform can limit the benefits you get from migrating to Next.js in the first place.

Migrating Legacy App to Next.js

Set Up Your Environment

Your migration needs a proper home from day one. Create a new Git repository or branch off your existing one. Create a new Next.js project with create-next-app, then connect the repo to Vercel or whatever hosting platform you chose. Set up CI/CD pipelines so every change deploys automatically.

You'll be able to test your migration progress in real time instead of waiting until everything's done to see if it works.

Build Reusable Elements First

A solid foundation will save you time and the headache of dealing with messy code. When you build base components and establish patterns upfront, you avoid duplicating code later and give your team clear examples to follow.

Start with your theme configuration. Set up design tokens (colors, typography, spacing scale, border radii, and breakpoints) early. These become your reference point for styling.

Then build your base components: buttons, inputs, cards, and other UI elements you'll use everywhere. Set up your typography system and decide on your styling approach, whether that's Tailwind, CSS Modules, or something else.

Getting this done first means every page you migrate looks consistent, and you won't need to refactor styles halfway through the project.

Connect the Data Source

With your base project ready, start connecting to your existing backend or CMS. This is where legacy data starts flowing into the new system.

Create API Route Handlers to bridge old and new systems.
Connect your external APIs and CMS platforms.
Implement authentication logic, configure server actions if needed, and add caching strategies to improve performance.
Test the server-side data flow to make sure everything works before you start building UI.

With this done, the rest of your migration project can focus on frontend work. If your legacy systems aren't ready yet, start with mock data and connect real APIs later.

Build Global Layouts: Header, Footer, and Shell

With the core setup ready, it's time to wire the application into the systems it relies on. Focus on establishing a reliable backend connection before moving deeper into the migration.

Break the work into a few clear steps:

Create API route handlers to set up endpoints for any server-side logic that needs to live inside the Next.js app.
Integrate external APIs and your CMS with internal APIs or third-party platforms.
Implement authentication logic to handle sessions, tokens, and permissions in a way that fits your future architecture.
Configure server actions and use them for operations that benefit from running securely on the server.
Add caching strategies and decide what should be cached, how long, and where.
Test Server-Side Data Flow to verify requests, responses, and edge cases so nothing breaks when you start layering in UI components.

A dependable data layer gives the rest of the migration momentum. Once these pieces are in place, your team can build pages without worrying about missing integrations or an unpredictable backend.

Move Page Sections One by One

Working in small, contained slices keeps the risk low, makes QA far more manageable, and helps your team surface issues early instead of discovering them at the end. Start shaping the content block by block, then assemble those blocks into complete pages. As you do, connect each part to the right data source and confirm that every state behaves as expected.

Add Redirects if Routing Paths Change

Updating systems often involves URL changes. However, they need to be handled carefully to avoid breaking SEO and analytics.

When the migrated system introduces a new routing structure, set up redirects() in Next.js to preserve the paths your legacy software relied on. If certain URLs must remain stable, add rewrite rules so old and new systems continue to resolve requests correctly throughout the migration process.

When everything is mapped, test navigation on both the client and server to confirm that search engines, integrations, and users all reach the right destinations.

Optional: Implement Monitoring

Even the best migration plan won't catch every issue. Setting up monitoring in place gives you a safety net throughout the migration process and once the new system is live.

Tools like Sentry or LogRocket surface problems like client and server errors, slow API endpoints, route performance drops, hydration mismatches, or unexpected regressions early. Your team can react before they turn into user-facing outages.

Ensure SEO Requirements Are Met

SEO can be harmed during data migration, so treat it as a core part of the modernization project.

Review every page to confirm titles, descriptions, OpenGraph fields, canonical tags, and previous SEO rules carry over correctly. It's also worth scanning the new layout for structural issues like duplicated H1 tags or missing alt text, which can affect rankings.

Next.js helps you protect (and often improve) organic visibility with features such as the Metadata API, dynamic OpenGraph fields, server-rendered HTML, route-level sitemaps, robots.txt, and built-in image optimization. Decide early how metadata will be generated and where custom logic is needed, especially if you're moving away from legacy systems with hardcoded SEO fields or CMS-driven templates.

Metadata Example

export const metadata = {
  title: "Your Page Title",
  description: "Your description.",
  openGraph: {
    images: ["/og-image.jpg"],
  },
};

Test Performance Early and Often

Keep an eye on performance while moving from your current system. Run Lighthouse and PageSpeed Insights regularly to confirm caching works as expected, Core Web Vitals stay on track, images are sized correctly, and your ISR/SSR logic behaves predictably. It will also let you spot any hydration issues early, long before they turn into bigger problems.

Next.js comes with many performance advantages, but those optimizations only pay off if they're configured correctly. Keeping a close eye on performance as you modernize the system helps prevent regressions, protects the gains you're aiming for, and saves your team time as the migrated system grows.

Add Testing & QA Before Launch

Before you wrap up the migration project, make room for a proper testing pass. It doesn't need to slow the team down, but skipping it almost always shows up later as production bugs, SEO drops, or unpredictable behaviour in the migrated system.

A solid QA layer usually includes a mix of unit tests (Jest or Vitest), end-to-end checks (Playwright or Cypress), accessibility scans, visual regression tests, and even simple dead-link audits. Together, these help catch layout issues, broken states, missing metadata, and any quirks introduced while moving legacy components into a modern architecture.

Treat this stage as the final safety net before the new system goes live. It's a chance to confirm you just conducted a successful migration.

Final Post-Migration Checklist

Use this checklist to make sure nothing slips through the cracks before your new platform goes live:

[ ] Routes and redirects verified
[ ] SEO data (titles, descriptions, OG tags, canonicals) carried over
[ ] Analytics and tracking reconnected
[ ] All UI states and edge cases tested
[ ] Performance benchmarks (Lighthouse, CWV) meet targets
[ ] Accessibility checks passed

Successful Legacy System Migration to Next.js

By the time you reach this point, most of the heavy lifting is done. You've modernized the structure, tightened up performance, protected SEO, and brought the legacy system to Next.js.

What's left is simply making sure the new environment behaves the way your team and users expect it to. A thoughtful rollout, a final round of QA, and clear internal communication will help the migrated system settle in smoothly. From here, your team can stop wrestling with older systems and start building faster, cleaner, and with far fewer surprises.

If you're looking at moving away from a legacy setup and want support from a team that's done this many times, reach out to us! Pagepro can help you plan and execute a smooth transition to Next.js and see what the best path forward looks like.

FAQ

What is an Example of a Legacy System?

A legacy system is older software or infrastructure that still runs critical operations but was built on outdated technology. Common examples include on-premise ERPs, custom CMS platforms, monolithic applications, COBOL-based banking systems, and websites running on outdated frameworks or databases. These systems often work reliably but limit modern development, integration, and scaling efforts.

Why are Legacy Systems Still Used Today?

Legacy systems stay in place because they run essential workflows, and replacing them can feel risky, costly, or disruptive. Many teams keep using them because the system is deeply embedded in daily operations, staff already know how it works, and the business relies on custom logic built over many years. The challenge is that staying on older systems slows innovation, increases security risks, and makes scaling harder.

What are the Disadvantages of Legacy Systems?

Legacy systems create ongoing problems as they age. They're expensive to maintain, hard to integrate with modern tools, and more vulnerable to security issues. Performance tends to drop over time, updates require more effort, and teams lose agility because old technology can't support new workflows, cloud services, or modern user experience standards. As technical debt grows, so do the risks of outages and compliance failures.

Is Replacing a Legacy System Worth It?

Replacing a legacy system is worth considering when the cost, risk, and operational drag outweigh the stability it provides. Modern platforms offer better performance, stronger security, lower maintenance costs, and more flexibility for future features. If a legacy system slows development, blocks integrations, harms SEO, or creates reliability issues, migrating to a modern architecture usually delivers a clear long-term return.

How to Replatform Your Website Without Trouble?

Mariusz — Thu, 09 Jul 2026 16:00:59 +0000

Is a Website Replatform Necessary?

Slow load times can seriously impact your sites or online store’s digital presence. Even hardcore digital marketers and SEO specialists will not be able to do much if your current website performs poorly, and a clunky site will turn away potential clients and affect your revenue. Perhaps it’s time to replatform your website.

If the user experience of your website is sub-par, the top of Google search results will remain out of reach. To get there, you’re going to need proper technical support to back up your content.

The goal of this article is to help you understand the process of migration better so that you can communicate your needs to developers more efficiently. We’re going to go over some symptoms which may indicate whether you need to start the replatforming project of your website.

What is Replatforming

Replatforming is migrating your data to a different CMS. There could be hundreds of reasons to migrate your data to a different platform. However, the most prevailing reasons are:

Slow website
Limited scalability
Bad customer experience
High maintenance costs
Limited integration features of your current CMS
Security issues
SEO in need of improvement

Replatforming can be a very cost-efficient investment. Kiwi Storage wanted to migrate from their WordPress website due to several limitations, including restricted functionality, reliance on external developers, and security concerns. Their migration allowed for better content management and integration of custom features. Not to mention a superb site performance!

A smartphone and a tablet display a storage company website built with a bespoke UI component library, showing the text Self Storage in London - We Collect, Store & Deliver next to an illustration of a green van and two people loading boxes.
And, as technology keeps moving forward, the businesses that are unaware of the new software solutions are simply falling behind.

Choosing a New CMS for Replatforming

When deciding to replatform, it’s essential to understand the differences between a traditional CMS and a headless CMS.

Headless CMS

A headless CMS, such as Contentful or Sanity, decouples the content management from the presentation layer. The content is stored and managed separately from how it’s displayed, allowing it to be delivered to multiple platforms through APIs.

Many businesses are shifting to headless CMSs for their performance benefits and the ability to create seamless omnichannel experiences. A headless setup can future-proof your website, allowing you to integrate new technologies more easily, but requires technical expertise to set up and maintain.

Migration to a headless CMS is a very common occurrence among businesses.

Lyngen North migrated to a headless CMS from WordPress to improve management and flexibility, addressing WordPress’s limitations in functionality and integrations. They needed a fast, high-performance site for high-resolution visuals without compromising speed. The switch to Sanity enhanced scalability, content control, and SEO optimization.

A website to replatform your glass igloo and house rentals is displayed on a tablet and smartphone, showing a night scene with northern lights above a glass igloo. The navigation menu and booking options are visible.
If you find out more about headless CMS, be sure to read our articles on the advantages of the headless approach and the 5 best headless CMS available on the market.

Traditional CMS

Platforms like WordPress and Drupal are traditional CMSs. They combine both the content management and presentation layers in one system, meaning the backend (where you create content) and the frontend (how the content is displayed) are tightly integrated.

While this approach can be easier to set up and manage, it can limit flexibility, especially when delivering content across multiple platforms like mobile apps, websites, and other channels.

How to Migrate Your Current Platform

Step-by-step vs all-at-once methods head to head.
There are two most prominent ways of replatforming a website. One is taking the time and migrating the data all at once. The other is migrating the data step by step.

Deciding to Replatform All at Once

Replatforming everything at once works well if you have clear documentation and a well-defined migration plan. Not everyone can afford a brief downtime for testing and deploying the site, but if you can or the old system is becoming too costly or cumbersome to maintain, migrating everything at the same time is a great choice.

Pros:

All your data is transferred at once
Unified user experience
Easier testing and debugging
Simpler project management

Cons:

It can be time-consuming
Your old website with all its issues will have to remain in use until the update

Switch Your Website to a New Platform Step-By-Step
Instead of replatforming and re-constructing everything at once, you can release the new version of your website step-by-step. To do that, your devs are going to be re-writing HTTP and directing traffic through path-based routing.

Step-by-step migration approach is best when your site is large, needs to stay operational at all times, or you have budget constraints. It’s also helpful if your team has limited capacity, as they can work in manageable phases instead of handling everything.

Pros:

You can deliver parts of the new website quicker
Add new features step-by-step
Replace problematic systems and infrastructure sooner
Deliver new functionalities for a better user experience

Cons:

Requires complex methods of integrating new modules with the old system while transferring data
Successful Replatforming Can Be Complicated
The best approach to replatforming depends on your specific situation.

If you have the time and want to introduce your new platform with a big launch, replatforming everything at once could make sense. But if you’re aiming to improve the customer experience as soon as possible, the incremental step-by-step method might be the better choice.

Keep in mind that whether you choose the step-by-step or the all-at-once method for migration without proper preparation, you’re still going to be running in the dark. It’s important to have the process figured out before you start to avoid additional costs.

If you do not have a clear-cut path to reinventing your website, you should consider hiring professionals to help you. In the long run, you’ll save yourself a lot of nerves and money.

Keep the Layout Consistent

First of all, the page content, the header, and the footer all have to be consistent throughout your pages. When replatforming your website, chances are you’re looking to create and launch an entirely new website. More often than not, this means switching to a new content management system and doing so while continuing to work on the old one can confuse you and your users.

To keep both the old and the new sites consistent consider either updating the old version with the new design or copying the design of the old version and applying it to the new one until the project is finished.

Don’t forget details like error pages and favicons. These might seem irrelevant, but they’re necessary to keep your website consistent.

Provide a Single Shared Session for the Entire Site

If you have a marketing background, you already the customer journey should remain as smooth as possible. To achieve this, we must apply a single shared session for the entire platform.

It’s no secret people generally find accepting cookies annoying, so it’s better to avoid forcing them to do this again each time your website switches from the old version to the new one.

More importantly in the case of eCommerce sites, you don’t want your customers to lose their carts when, for example, moving from the cart section to the transaction section. This small issue could end up costing a lot of money and customer loyalty.

Check Third-Party Scripts and Tags

Regardless if you’re using WordPress, Sanity, or any other content management system, you’re no stranger to 3rd party tools integration.

Oftentimes analytics tools for ad tracking and site verification like Google Pixel are installed in both the and parts of your websites.

To keep things consistent, be sure these get either transferred or replaced so your site can keep collecting the necessary data. You don’t want to lose your analytics tools during the replatforming process!

Include the New Site’s Pages in the Sitemap

A sitemap is an .XML file that holds information about different elements like pages, images, videos, and all the other files on your website. It also includes important information about all of the relationships between them.

To ensure the proper functionality of your new site, your developers have to remember to include all the pages from the new site in the sitemap. Create an index file with sitemaps from both the new and the old versions of your website.

Do I Need to Migrate My Website?

The crucial part is to recognize whether your website’s performance issues aren’t slowing your business down or impacting search engine optimization. Then, once you’ve recognized the problem, it may be time to make an educated choice of deciding to go all out and migrate all of the data at once or do so through the step-by-step method. You might want to reach out for professional help in new system integration or even a website audit to optimize the migration process.

While you might be tempted to invest in paid ads and promotions, these will not bring you the benefits you’re looking for if your website is not up to the task. Replatforming and maintenance costs will be nothing compared to what you are bound to lose in the long run if your existing website lacks in performance and doesn’t suit your business needs.

Why is Gatsby JS Good for Google Rankings?

Mariusz — Fri, 18 Sep 2020 12:34:10 +0000

SEO, which stands for Search Engine Optimisation), doesn't seem to get old — it's just different every year. Google changes its Search Algorithm and Ranking System every once in a while, adding new ranking factors or modifying existing ones. And since 2018, the page speed is one of them.

However, there are more: content relevancy, mobile-friendliness, user experience, on-page optimisation... There are more than 200 of them in total. It's mind-blowing, isn't it?

However, you don't have to take them all into account — focus on the most important ones.

And if you are wondering how to do that and create a website with the highest chances to rank high, consider Gatsby.

Keep reading to check why!

What is SEO?

Search Engine Optimisation (SEO) is a set of practices aimed to make a particular website look better and better in the eyes of Google. In other words, SEO is about improving the quality and quantity of website's traffic coming through search engine results pages (SERPs).

Search engine result page, on the other hand, is a page that displays mainly (but not only) results returned by a search engine like Google as a response to query search such as "online shopping" or "front-end development agency".

Why does SEO matter?

SEO helps companies bring valuable, organic traffic to their websites which is the first step towards getting new clients and increasing revenue. The better SEO-optimised the site is, the higher it's ranked in SERPs. And the higher the ranking is, the bigger the traffic.

The main difference between organic traffic (brought by SEO) and paid traffic (brought by money) is that the first one is free, forever. However, great SEO has more benefits than just saving money:

It drives the quality traffic to your website — instead of reaching out to people whether they want to or not (interruption marketing), SEO focuses on making it easy for them to find you when they want to (permission marketing).

Organic results get more clicks than paid ads — it's hard to tell why that is, but it doesn't alter the statistics: over 70% of searches end in clicking an organic result on the first page.

SEO supports Public Relations efforts — one of the main elements of SEO is link building, which is about earning links from industry-respected publications and other relevant websites. On the other hand, featuring in such publications and being mentioned by influencers is a primary point of PR strategy. This presents an excellent opportunity to get in front of new customers through, for example, guest posting.

It helps you to overtake the competition — SEO is an essential part of most marketing strategies which means there is a huge chance that your competition is already fighting for better rankings. However, with well-prepared and well-executed SEO efforts, you can catch up with them or even surpass them.

Main SEO ranking factors

There is a legend circulating in the marketing world that there is a man who knows all SEO ranking factors used by Google. However, no one ever saw him.

Luckily, you don't have to know them all – only the main ones. But since giving specific SEO advice is not our goal here, we will just scratch the surface to provide you with an overview.

Accessibility

All your efforts to rank high will be for nothing if your website is not visible to search engine crawlers. These are robots that are crawling through the Internet to index websites. If the specific site is not indexed correctly, it won't be displayed in search results.

What you have to do is create robots.txt file and website's sitemap. It's a confirmation of your site's accessibility. However, you can go one step further by submitting your website to Google through Google Search Console.

Backlinks

This is one of the most crucial SEO ranking factors, if not the most crucial one. As a reminder, backlinks are links to one website inserted on another website. The more backlinks you earn, the better it is for your website's SEO.

However, it's more complicated than it looks like. Every single backlink and its effect on SEO is influenced by other factors like relevancy or domain authority.

Mobile-friendliness

Mobile-friendliness (or responsiveness) is a ranking factor for both mobile and desktop searches. If your website fully adapts to a visitor's device — whether it's a small-screen mobile phone or big-screen TV — it means that it's mobile-friendly (or responsive). And this is very much welcomed by Google.

You can check if your website is mobile-friendly with Google's official tool.

On-page optimisation

All efforts within the website that are intended to improve the website's position in search engine results are called on-page optimisation. Among them are: creating proper title and meta tags, using the right keywords, optimising images, writing original and valuable content.

Page speed (desktop and mobile)

Page speed has been a ranking factor for a decade now. And two years ago it started to affect not only desktop searches but also mobile searches. However, don't treat it like a challenge to beat competitors by trying to make your website load a few milliseconds faster. Instead, make it fast enough, so it won't affect the user experience negatively.

One more thing: according to Google's research, one-third of visitors will leave your website if page load time goes from one to three seconds. If it takes longer, it's even worse.

User experience

Would you come back to a place where you have had a terrible experience? Doubtful. The same thing goes for websites — the first impression makes all the difference. If the user experience is awful, it's likely you won't revisit it.

While it's not clear how exactly Google measures user's satisfaction from visiting a particular website, they gave some suggestions about what's essential from the UX perspective:

Content that's useful and easy to read
Design that's responsive and responds to users' needs
Well-organised site architecture

Dynamic site vs static site: which one is better for SEO?

There is one more thing to consider: what kind of website should you choose to raise your chances of ranking high in search engine results pages. First of all, there are two main website types — dynamic site and static site.

What is a dynamic site?

Dynamic sites allow users to interact with the content posted on a website. That content is being generated in real-time, which means it can be different for different users, depending on their location, device, time zone, or even network.

A dynamic website can use client-side scripting (the browser executes code), server-side scripting (the server runs code) or a combination of both.

A good example of such websites are those built using a Content Management System (CMS) like WordPress or Drupal.

What is a static site?

Static websites, on the contrary, offer the same content for every visitor, regardless of their browser's language or other preferences. For every page, there is a specific HTML file on the server that contains the content of this page. Such a website is pre-rendered and is not meant to be regularly updated because it requires some HTML knowledge to edit source files.

A good example of such websites is simple business websites created using static site generators (SSG) like Gatsby.

Which one does Google prefer?

While both types serve different purposes and require different skills, let's take a look at dynamic sites and static sites from Google perspective.

Static sites are faster.

Page load speed is one of the leading SEO ranking factors, which also affects user experience in either a good or bad way. Static sites are faster than dynamic sites because they are pre-rendered. Pre-rendering means that your website is generated as a set of static files in advance, not in real-time.

Static sites are easier to index.

Static websites consist of HTML and CSS files which are extremely easy to read and index by Google crawlers. Another thing that helps with indexation is a simple sitemap which is recommended by all search engines, including Google.

Static sites are easier to optimise.

When you decide to choose a static site, you gain total control over SEO. You can customise any page of your website in any way you want. In a case of dynamic websites, you need to install a plugin or two to help you with SEO efforts.

Static sites are less expensive to host and maintain.

Since static sites consist of simple HTML files, they need much less space on the hosting server than dynamic sites. Also, such a website won't use much of the monthly transfer limit.

What is Gatsby?

If you are considering creating a static site, Gatsby may be your choice of tool to do so. It is a free and open-source framework created with React, helping developers to build blazingly fast sites and apps. Gatsby is also called static site generator (SSG).

Why is Gatsby good for SEO?

It's time for the most important part of this article. I haven't jumped straight to that from the beginning because I wanted to explain the context. So far, you found out:

what is SEO
what does it matter
main SEO ranking factors
which one is better for SEO: dynamic site or static site

It helped you to understand the whole picture better, right?

Now it's time to find out why Gatsby is good for SEO.

Accessibility

Web accessibility means that websites, tools and technologies should be designed to be accessible for everyone, especially for those with permanent or temporary disabilities. When it comes to Gatsby and its accessibility, WebAIM (Web Accessibility in Mind, non-profit organisation) recognised Gatsby as the most accessible web framework.

Gatsby uses different practices to make its websites as much accessible as possible:

Accessible routing — the main feature of every website is navigation, and accessible routing takes care of that. Thanks to it, you can, for example, use a keyboard to navigate through the website. Also, Gatsby manages page announcements on page change.
Building HTML pages by default — since it's using Node.js environment to compile pages, you don't have to worry about progressive page enhancement. Progressive enhancement means that the core page content is loaded before anything else from the server.
Linting using a plugin — Gatsby uses an eslint-plugin-jsx-a11y package that reduces the time needed to find accessibility errors. This plugin, among other things, encourages you to add alternative text to all images.

Page metadata

Gatsby gives you full control over the website's content and structure, and consequently, over the SEO of this website. You can add metadata like page titles, meta descriptions and alt text, which helps search engines to understand the content on your website and when to display your site in search results.

To add metadata to your website, you can use react-helmet components. Remember to add Gatsby React Helmet plugin to support SSR (server-side rendering).

Performance and speed

Gatsby is all about performance and speed. It comes with built-in features like rendering to static files or progressive image loading which are responsible for making Gatsby website fast. According to 2018 Google's update, site speed became the new ranking factor, and faster websites will likely rank higher than the slower ones.

However, you should still create content that's valuable and relevant to visitors, because the slower but more relevant site may rank higher than the faster ones.

Structured data

Structured data is what Google looks for on the web to understand the website's content. This is also its source of general information about the web and the world.

The better Google understands the content, the more relevant search results are. In other words, if you use structured data on your website, it helps you to rank higher.

In Gatsby, you can add structured data snippets with react-helmet in the JSON-LD (JavaScript Object Notation for Linked Data) format, which is embedded either in the page head or page body.

User experience

All the points made above ensure great user experience to visitors. And it's not just about the site speed — with Gatsby you can create fully customised websites that are accessible to everyone, easy to find and navigate, and visually attractive.

Examples of Websites built with Gatsby

Many well-known companies decided to build their websites using Gatsby — Airbnb, Bitcoin.com, Braun, Spotify, to name a few. However, there is no limitation on who can use Gatsby because startups and small companies also choose it.

Check below examples to see how such websites look and perform:

Airbnb Engineering & Data Science
Bitcoin.com
Braun
Frame.io
Hopper
Spotify.design
Frontend Day conference created by Pagepro
JS Minds created by Pagepro

Many well-known companies decided to build their websites with Gatsby — like Braun, Spotify and AirBnb, just to name a few.

Alternatives to Gatsby

We highly recommend Gatsby to build static sites, but we also would like to help you make a fully informed decision. Because of that, we wrote about Gatsby alternatives — you can read about them here.

Is React Native Good for Startups?

Mariusz — Thu, 03 Sep 2020 13:37:45 +0000

Building a startup is like driving a sports-car. It's fun, it's exciting, but it is also about fast yet wise decisions. Making mistakes is not an option, and the danger is high. You may either crash your car or run out of gas before getting to your planned destination.

If you want to avoid this, choose your vehicle and engine that comes with it wisely. And reading this piece will help you to decide whether choosing React Native for startups is actually a good idea.

What is React Native?

React Native is an open-source, cross-platform framework created by Facebook in 2015 for building mobile applications using React. It's like an engine for your startup's app. It allows developers to accelerate the development of native apps for operating systems like Android and iOS.

React, in turn, is a JavaScript library, which was created to build user interfaces.

If you want to become more familiar with React Native, read our comprehensive guide.

Which startups use React Native?

React Native is a choice for many companies, from tech giants like Facebook itself to young startups looking for funding. If you are curious, here is the list of some popular applications that have been built using this trend-setting technology:

Discord
Facebook
Facebook Analytics
Instagram
Pinterest
Skype
Salesforce
Uber Eats

There are more examples, but it all comes down to this: if they rely on React Native, why shouldn't the others?

And that’s just the way startups that use React Native like Mattermost (self-hosted open-source Slack alternative) or Oval (creators of personal finance app) think.

When to consider choosing React Native?

Choosing the proper technology for your mobile application is challenging. But it may become a bit easier after reflecting on needs, estimated budget and available time. Therefore, there are some scenarios in which React Native might be the right choice. Consider choosing React Native:

If you have native apps already— if you already have iOS and/or Android applications, you can change to React Native, because it doesn't require re-writing the entire code which makes migration a lot easier (check here how Khan Academy managed such a transition)
To scale quickly — it's easy to hire or train React Native developers so growing a team fast is not a problem.
To create MVP fast — having just an idea is not enough, and you must test it in real market conditions. In other words, you need to create an MVP as fast as possible.
If you have tight deadlines — if you work in a startup, you need to move fast. Need-for-Speed-like fast or even faster. And it's not about creating MVP. It's also about making constant changes and updates with as little effort and time as it's needed.
If your budget is strictly limited — having just an idea is not enough for most investors. A minimum you need is working MVP, but there is a chance that you won't finish it before running out of money. Using React Native will help you minimise that risk.

Benefits of using React Native for Startups

Looking closely at benefits is always a good idea when it comes to making more or less important decisions. To help you make a great one regarding technology for your startup, we prepared a list of benefits from both business and technical perspectives.

Benefits from a business perspective

Excellent User Experience — User Experience of any digital product is essential to its success. While technically a React Native app is not "the app", it looks and feels like it. Especially because it's fully responsive.
Stability and evolvement — since its foundation, React Native matured, is still evolving and backed up by a huge community. Most common problems are already solved. Therefore, the risk of using it doesn't exist.
Developers availability — React Native is not a new technology or one that nobody knows. The reverse is true: the developer marketplace is robust. You can either hire freelancers using websites like Upwork or talk to an agency like ours.
Shortened time to market (TTM) — the sky is the limit, and time is the money. As a startup, you don't want to create an app for months without showing it to real users and future customers. React Native boosts up mobile development up to 50% in comparison to native app development so startups can create working MVP even twice as fast.
Money savings — this point is highly connected with the previous points. Still, there is more: a decision to build a single cross-platform app is far better economical choice than creating two separate applications for iOS and Android.
Time savings — using React Native means that you don't have to create two separate applications for two separate platforms. Not to mention the time you will spend on upgrading and fixing them.

Benefits from a technical perspective

Compatibility with back-end technologies — you can use React Native with back-end frameworks like Django or Ruby on Rails, and it will work like a charm
Declarative style — it's about WHAT you want to do, in a contrary to imperative style, which is about HOW you want to do it. For example, let's say that you hired a private chef and want to eat a fancy dinner at home. Instead of telling him HOW to do it (imperative style), you just say WHAT you want (declarative style), i.e. "Make me Hawaii pizza, please."
Dynamic development — since its creation in 2015, React Native evolved both as a technology and community, and it doesn't seem it will rest on its's laurels. Because of that, you can be sure of two things: (1) it's more future-proof than some other technologies and (2) the chances of finding someone to hire or to help you are very high.
Hot Reloading — in short, it allows you for making changes to your app code while it's still up and running. It accelerates app developments significantly because your app can reload automatically.
Open-source community — if you are stuck somewhere along the development process, you can always go to GitHub or Reddit to ask for help, and there is a great chance that someone will help you out
Reusable components — why write the same code again and again, when you can re-use already-built elements? It works across both iOS and Android, and it's enough to update a particular component in one view. It's possible because updates will be automatically made in each case of using this component
Third-party extensions support — React Native is all about speeding up the development process. Apart from RN itself, you can use many third-party plugins and frameworks like NativeBase (which helps you to create native-like apps) or Galio (which is a library of UI components)

Disadvantages of using React Native

Unfortunately, it's not all rainbows and butterflies. Like any other technology, React Native also has its flaws:

Complicated updating process — keeping your cross-platform application always up with the latest React Native version is a challenge. It's a complicated process that's much easier in the case of native apps.
Issues with more complicated design — React Native may not be the best choice if you want to use gain business leverage by using some advanced interactions or custom graphics
Lack of custom modules — sometimes, you will have to build specific components from scratch.
Messy code after migration — you may have to rewrite some code to make necessary adjustments or to make APIs work correctly again.

When to choose a native app instead of React Native?

It’s not like that cross-platform app is always a better choice than going with a native app. There are some scenarios in which it's better to choose the latter option. Consider native app if:

Performance is what you care most about
Security is your priority, i.e. if you are in the FinTech industry.
Your app will be heavy on graphics. In other words, if you want to include advanced interactions, custom animations, or various screen transitions in your app.
Your app will require a lot of interactions with hardware like GPS, i.e. if it uses geolocation tracking.

Alternatives to React Native

Flutter — it's a framework created by Google to build mobile, web, and desktop applications using a single codebase. To find out more, read our comparison between these two.
Xamarin — it’s a framework created by Microsoft, which allows developers to build iOS and Android applications. But in a contrary to React Native, Xamarin apps are written in C#.
Ionic — thanks to it, developers can use standard web technologies like Javascript, HTML and CSS to build cross-platform mobile applications. The difference between React Native and Ionic is that Ionic is hybrid, and the RN is native.

All of the above alternatives are cross-platform and open-source solutions.

React Native FAQ

How long does it take to build a React Native application?

The reply is: it depends (it’s our favourite answer). While choosing React Native to build an application speeds up the development process up to 50% in comparison to native app development, the time needed depends on the complexity of the desired application.

Such an estimation can be prepared after outlining the software complexity by both sides.

How much does it cost?

Again, it depends. Development agency can give you a ballpark estimate of your project, including time and money needed, after outlining its complexity.

What's next?

If you are more like a reader, you can check our comprehensive guide on React Native.

Using Next.js as a Static Site Generator

Mariusz — Fri, 21 Aug 2020 09:55:10 +0000

Static Site Generators are becoming extremely popular in the world of web development and Next.js is a proud competitor in this race.

What are Static Site Generators?

🚀 STATIC = BLAZINGLY FAST 🚀

Static Site Generator are extremely fast. Once loaded, they prefetches resources for other pages so clicking around the site feels like a blonk of an eye.

💎 STATIC = SAFE 💎

You will just publish static files, which means there is no direct connection to the database, dependencies, user data or other sensitive information.

😎 STATIC = ENHANCED USER EXPERIENCE 😎

Simply because clicking and walking through your website feels like a walk in a park on a sunny day with no unexpected turns, stairs, or dead ends.

What is Next.js?

“Next is a framework which we can use to build React sites with Server Side Rendering or generate static pages from our react code. All that configured for us by Next itself.”

And in this post we will be taking a look at the static pages export functionality and how we can make it with next.js.

Let's go!

Creating an app

We will start by creating a new next app. To do that simply run the command:

yarn create next-app
# or if you are using npm
npx create-next-app

Now, let’s take a look at our project structure:

pages - this directory contains all our pages and defines routing for our app (more about routing here).

pages/api - here we can add our API endpoint if we need some, in our case we can remove this folder safely (more about API routes here).

public - we can put all our static assets in this directory.

Let’s change our commands to reflect what we want to achieve in this project. Got to package.json and modify scripts section like this:

"dev": "next dev" -> # remove
"build": "next build" -> "build": "next build && next export"
"start": "next start" -> "start": "next dev"

So now our scripts section should look like this:

{
  ...
  "scripts": {
    "build": "next build && next export",
    "start": "next dev"
  },
  ...
}

Now we can test our configuration, run the build command:

yarn run build
# or if you are using npm
npm run build

Next should create out directory at the root of our project with all the static html files and assets ready to host. We can change the out directory by adding a -o flag to our next export command like this:

{
  ...
  "scripts": {
    "build": "next build && next export -o build",
    ...
  },
  ...
}

Adding content to page

Let’s head to pages\index.js file and remove the content of Home component and change it like this:

const Home = () => {
  return (
    <p>
      Hello From my next.js app!
    </p>
  )
}

export default Home;

And start our app by running command:

yarn run build
# or if you are using npm
npm run build

Now you should be able to access http://localhost:3000 and see our Home component content.

Now let’s add some content that will be evaluated at the build time. We can do that by using getStaticProps which is a function exported from our page. As we don’t have any data source configured yet we will do a simple example to show how getStaticProps work.

const Home = ({ buildTimestamp }) => {
  return (
    <p>
      Hello From my next.js app!
      App built at: {buildTimestamp}
    </p>
  )
}

export const getStaticProps = () => {
  return {
    props: {
      buildTimestamp: Date.now()
    }
  }
}

export default Home;

We will see that buildTimestamp changes every refresh, this will not be the case when we build our app because getStaticProps is called only once when app is building.

Adding data source

We already know how getStaticProps works, now we can make it more useful and add some external data source to our app. Next.js doesn’t come with any data provider built in (for example GatsbyJS has graphql) so we will have to add it manually.

Basically you can load your data however you like. In this tutorial we will use GraphQL with Apollo Client. First let’s add src directory where we will keep all our code shared between pages. Then create src\setup\apolloClient.js file where our apollo client will be created.

import { ApolloClient } from "apollo-client"
import { HttpLink } from "apollo-link-http"
import { InMemoryCache } from "apollo-cache-inmemory"

const apolloClient = new ApolloClient({
  link: new HttpLink({
    uri: 'https://gitlab.com/api/graphql',
  }),
  cache: new InMemoryCache()
})

export default apolloClient

Additionally we will have to install some apollo realated packages. Simply run the command:

yarn run add apollo-cache-inmemory apollo-client apollo-link-http graphql graphql-tag
# or if you are using npm
npm install --save apollo-cache-inmemory apollo-client apollo-link-http graphql graphql-tag

As you can see we will be using GitLab graphql api (explorer is available here).

Creating pages and fetching data

Now we can fetch some data, let’s fetch some repositories. First we have to create graphql query:

const PROJECTS_QUERY = gql`
  query {
    projects (first: 10) {
      nodes {
        id
        name
        description
      }
    }
  }
`

Now we can import apollo client and use it with above query in our getStaticProps:

export const getStaticProps = async () => {
  const { data } = await apolloClient.query({
    query: PROJECTS_QUERY
  })

  return {
    props: {
      projects: data.projects
    }
  }
}

Now list of GitLab projects is available in our Home component props, let’s render it.

const Home = ({ projects }) => {
  return (
    <ul>
      {projects.nodes.map(({ name, description, id }) => (
        <li key={id}>
          <p><strong>{name}</strong></p>
          {description && <span>{description}</span>}
        </li>
      ))}
    </ul> 
  )
}

And that’s it, we have a working GitLab projects list.

Now let’s add project detail page.

First we have to add dynamic route to our app, we can do that by creating a file with square brackets in its name, like this:

More about dynamic routing here.

When we are building our pages statically Next.js requires us to export a function called getStaticPaths from our page.

We have to do that because Next.js needs to know all the page urls and their params at the build time. We have fetched first 10 Gitlab projects at our homepage so now we have to do the same in our getStaticPaths to generate urls.

First let’s add links to projects details on homepage. We have to add fullPath field to our query:

const PROJECTS_QUERY = gql`
  query {
    projects (first: 10) {
      nodes {
        id
        name
        description
        fullPath
      }
    }
  }
`

And render next link for every project:

const Home = ({ projects }) => {
  return (
    <ul>
      {projects.nodes.map(({ name, description, id, fullPath }) => (
        <li key={id}>
          <p><strong>{name}</strong></p>
          {description && <span>{description}</span>}
          <div>
            <Link
              href="/project/[...fullPath]"
              as={`/project/${fullPath}`}
            >
              <a>Details</a>
            </Link>
          </div>
        </li>
      ))}
    </ul>
  )
}

Now we can add code to our project details page:

import gql from "graphql-tag";
import apolloClient from "../../src/setup/apolloClient";

const ProjectDetailsPage = ({ fullPath }) => {
  return <>Project details page {fullPath}</>
}

export default ProjectDetailsPage;

const PROJECTS_QUERY = gql`
  query {
    projects(first: 10) {
      nodes {
        fullPath
      }
    }
  }
`

export const getStaticPaths = async () => {
  const { data } = await apolloClient.query({
    query: PROJECTS_QUERY,
  })

  return {
    paths: data.projects.nodes.map(({ fullPath }) => ({ // 1
      params: { fullPath: fullPath.split('/') },
    })),
    fallback: false, // 2
  }
}

export const getStaticProps = ({ params }) => {
  return {
    props: {
      fullPath: params.fullPath.join('/') // 3
    },
  }
}

Let’s explain some key parts here:

We map our projects list to an array of paths required by Next.js. Structure that Nexts.js expects looks like this:

{
  paths: [
    {
       params: {
         (all params that we want to pass to getStaticProps)
       }
    }
  ]
}

Also when we use Catch All route we have to pass our param as array that’s why we use split here.

We have to tell next if we want to render missing pages live or just return 404. In our case we are making fully static page so we define fallback as false. More about fallback here.
We merge our fullPath param to single string so we can display it nicely in our component.

Now we can change getStaticProps to be more useful and fetch some project data for us. First we need query for project details:

const PROJECT_DETAILS_QUERY = gql`
  query ($fullPath: ID!) {
    project(fullPath: $fullPath) {
      name
      descriptionHtml
      repository {
        empty
        tree {
          lastCommit {
            sha
          }
        }
      }
    }
  }
`

And run it inside of our getStaticProps

export const getStaticProps = async ({ params }) => {
  const fullPath = params.fullPath.join('/');
  const { data } = await apolloClient.query({
    query: PROJECT_DETAILS_QUERY,
    variables: {
      fullPath
    }
  })

  return {
    props: {
      project: data.project
    }
  }
}

Now we can display some data on our project details page:

const ProjectDetailsPage = ({ project }) => {
  const {
    name,
    descriptionHtml,
    repository: {
      tree
    }
  } = project
  const { lastCommit } = tree || {}
  const { sha } = lastCommit || {}

  return (
    <div>
      <h1>{name}</h1>
      <p dangerouslySetInnerHTML={{ __html: descriptionHtml }} />
      {sha && <p>Last commit SHA: {sha}</p>}
    </div>
  )
}

And that’s it, we have created a static page displaying first 10 GitLab projects and their details.

We can now build it and serve to check if everything is working properly.

yarn run build
# or if you are using npm
npm run build

# if you are using yarn and don't have serve installed run this command first
yarn global add serve


# if you are using yarn
serve ./build
# or if you are using npm
npx serve ./build

Access the full project here.

Next.js vs GatsbyJS

As we can see Next.js can successfully generate static pages like GatsbyJS does and someone could ask:

“Can Next.js replace GatsbyJS?”

You can do all the things in Next.js that you do in GatsbyJS but it take much more time because you need to do everything by yourself.

GatsbyJS has a lot of plugins that help to solve many problems and optimize the page. More than that it has data fetching features built in (graphql available out of the box). So for now we will have to wait for Next.js ecosystem to grow and get more plugins so we can create static pages as fast as we do in GatsbyJS.

Keep in mind that Next.js has one big advantage over GatsbyJS:

you can create and app which is partially static and dynamic.

For example you can prerender first 10 posts from your blog and the rest can be rendered when the page is requested by user.

So for now Next.js is just a more flexible solution that requires more work and gives us some powerful extra features but in terms of development time GatsbyJS is still better.

React Native Code Review - A Checklist

Mariusz — Tue, 04 Aug 2020 13:34:47 +0000

Did you ever want to do a code review of React Native app by yourself?

If yes, let me guide you through the whole process, step-by-step with our own checklist.

But if you are quite new to the subject of code review, let's start from the basics.

What is Code Review?

Code review is a form of deep and profound analysis of the existing codebase. It comes with a set of specific activities and checklist points that leads you step-by-step through the process of identifying and uncovering current and potential bugs and problems.

When Should I Do a React Native Code Review?

Different React Native Developers face different scenarios, but it doesn't matter if:

you just took over an app from a different developer, or
someone asked you to improve the existing app, or
you just built an app and want to make sure it’s flawless…

…you need to have a deep understanding of what’s inside and where the potential source of errors may be hidden.

And if you think about it, there may be many areas that code review will appear to be highly recommended, if not absolutely necessary.

Improve Performance

First of all, code review is extremely important if it comes to app performance.

While talking about React Native and the cross-platform applications in general, their performance and user-interface is considered sometimes as the biggest challenge.

The goal is to make the final experience native-like. Which means performance has to be outstanding.

And this is when the code review is a great idea, as it is able to uncover many flaws and areas of improvement.

Scale Easier

Planning your future app improvement demands a deep understanding of its architecture.

The analysis of a fundamental app functionalities will help you plan how actually you can improve it later on.

After Changes and Improvements

As you know it’s almost impossible to build and release an app without few changes here and there. React Native apps are no different.

Keeping a code review checklist on your sight makes it easier to keep your app in shape despite the changes you have made.

React Native Bug Fixing

Even if you went through and passed many different tests, it doesn’t really mean your app is totally ready to hit the market.

Unfortunately many bugs are becoming visible only after a bit heavier usage by the final users.

Deep analysis of your code is able to spot them, before they arrive.

Detect Platform-based Functionalities

While building React Native applications, you will probably have things working on one platform (f.e. iOS), but not working on the other (Android).

Code audit helps you detect those “platform-based” features and functionalities, and fix them at an early stage.

Before Final Release

React Native code review is also a great way (and quite obvious) for a “final checkup”.

Before the release you may want to check if all works fine, and if the code is following the latest development standards.

Reasons Summary

To sum it up, React Native code review may be helpful to:

Find areas of improvement for your app performance
Get a deep understanding of the app architecture to scale it easier
Identify and uncover existing and potential bugs and problems
Identify “platform-based” functionalities
Keep your app in shape despite constant changes
Prepare your app to be released with no flaws
Making sure your app is following the latest development standards

How To Do a React Native Code Review?

If you want to do your code review well, I suggest to start going with the following order:

Primary audit - in this stage you go through the app structure and the fundamental functionalities.
Automatic analysis - in this stage you push the code through the most popular automatic test engines to uncover the most frequent issues and common violations.
In-depth analysis - this is the manual part, where you extensively go through our list to uncover bugs, performance issues, potential future problems, security vulnerabilities, etc.

React Native Code Review Checklist

Enough theory.

Let’s get to work. Here’s your React Native app Health Checklist, step-by-step:

1. Versions

First, check if:

React Native version is up to date.
All dependencies are up to date.
Dependencies (that use RN linking) are not deprecated and supporting latest RN version.
Dependencies in package.json are meeting the industry standards.

2. Development

Then, check if:

App is ejected/use Expo.
App got own native modules written (no support from npm).

3. Code Quality:

After that, check if:

Tests are written.
There is a typing solution implemented (TypeScript / Prop Types / Flow).
Code follow best practices.
Eslint and/or prettier is added.
Codebase has consistent code style.
Code is easy to understand (self describing) so we can make changes without trying to understand logic for a week.
Check imports through files (unused imports).
Check most common usage native files and code quality in it (MainApplication etc).

4. Test Run

Finally, check if:

Development tasks are running.
Build is working for any platform (Android, iOS).
There are no problems with putting apps in stores.
There are any CI/CD processes implemented.

Summary

React Native Code Review may appear an important step in your app development process.

It helps you understand the app taken over from another developer, helps you uncover the potential problems and bugs, and finally, makes your app ready for the market.

If you do it well, you can save yourself tons of work, and will make your app working well for a long time.

2020 Report: React in a Business Perspective - Key Takeaways

Mariusz — Thu, 25 Jun 2020 10:50:18 +0000

Many years ago, we chose React.js and React Native as the core of our technology stack.

The longer we were working with it, the more we were satisfied with our choice, and we quickly gathered a team of React developers totally dedicated to this library.

However, we started investigating if this love wasn’t just a quick affair.

A “halo effect”, or the BS talk we’ve been selling ourselves to help us believe we do the right thing, just because we are already doing it.

So, we took the laptop, and we’ve interviewed CTOs and Dev Team Leaders to check if choosing React and React Native somehow impacted their everyday work, and ultimately, their business outcomes.

What we have discovered?

TL;DR you probably guessed: most of them shared our enthusiasm.

In this article, I will show you the most important takeaways from 2020 React Report that will tell you:

Why did they choose React?
What actually changed since they made that choice?
And what are those business benefits they are taking the advantage of?

Sit back, relax, and learn how modern technology can help you make your business more efficient.

Or go directly to the Report.

What we knew and re-discovered about React

There are many benefits of using React.js, and benefits of using React Native, however, I will use the words of our survey Guests:

React saves you time and money

As every single web technology is trying to be more efficient (make things faster and easier to do), we asked CTOs if React development is going in that direction.

a good technology and is moving in the right direction">

React boosts your team productivity

Since we started to work with React, we could experience a productivity boost. All the developers were more excited about the technology, as we could do much more with less effort.

However, we wanted to make sure it’s not only our delusion.

CTOs want to use React

We could see in other surveys, as well as we have received many signals from the market, that React became and is still on the top of the most wanted and loved libraries.

This time we asked if people are still interested in using React, after experiencing it in previous projects.

What were the reasons behind choosing React?

We wanted to go deeper and discover more reasoning behind choosing React as a core of the technology stack.

That was an open question, below the most interesting answers from our respondents:

Easy to learn and easy to use.
Performance and reusability.
Development time.
Code sharing between web, iOS, and Android. What used to be 3 distinct codebases is now basically one.
Choosing a stable and large developer ecosystem
Time to market and ability to solve (most) bugs from a single code base.
More in the 2020 React Report

Key Business Takeaways

React is making time to market shorter and allows solving (most) bugs from a single code base, which makes software delivery more efficient.
React has a stable, large developer ecosystem and a wide market of available talents.
Thanks to component-oriented approach and cross-platform features React is an easily scalable way of building large-scale web & mobile (sometimes also desktop) apps.

What were the doubts behind choosing React?

Just the same as in the previous question, we wanted to go deeper into reasoning, yet this time, we asked our respondents about the doubts they had before they made the choice.

Before trying React we were already using Backbone, Ember, and Angular. We were afraid that we might be spreading our skills too thin and we were not going to be actually experts in any of those technologies. Fair to say that from the above, React is the only one left in our stack.
Difficult to learn, adds a layer on top of native code. Often you end up having to know native fundamentals anyway.
Dependency management across platforms.
A massive change in the approach meant that there is a risk that we’re spending all the time trying to skill up for nothing. However, it turned out it was time well spent.
Is it stable enough?
More in the 2020 React Report

Key Business Takeaways

While implementing new technology to the company’s stack it’s important to check if:

This particular technology is stable enough.
Is it able to fulfill your company’s needs?
How to train your current dev team or hire new people with solid commercial experience?

The biggest advantages of React

Obviously, we couldn't skip this question.

Reusable components have benefited several recent projects that we’ve been involved in.
Ecosystem, dev tools, new frameworks based on React are amazing.
From a front end perspective, we have much more control over the performance and perceived loading times of any React site.
It allows us to add iOS and Android apps to our offering as we can now use React Native in-house.
Our web portals are very high quality in terms of visible user bugs.
Agility and ability to build new MVP features fast.
Increased speed and decreased cost.
Having one way of building front-ends, across mobile apps and web apps.
More in the 2020 React Report

Key Business Takeaways

While implementing new technology to the company’s stack it’s important to check if:

After implementing React, organizations can increase development speed and decrease development costs.
Thanks to React, a single team can manage multiple apps on different platforms.
React allows companies to build a shareable, reusable library of inhouse components that can be used in different projects, prototypes, and platforms.

And much more

This is just a small part of the whole 2020 React Report.

Now, we have a clear signal on the real impact of React on the business layer.

What you can learn more from the Report?

What is the future of React?
The best React alternatives?
What are the threats of React?
How hard it is to hire and onboard React developers?
What is still missing in React?

Enjoy, and don’t forget to share it with people that may benefit from it.

Also, send me your feedback, and if you want to take part in the next year’s survey, let me know!

React Native vs Flutter

Mariusz — Thu, 18 Jun 2020 13:05:33 +0000

Demand for cross-platform applications is increasing. People are constantly searching for more optimal solutions such as React Native or Flutter, where they can create iOS and Android apps using one codebase only.

While using a single codebase for two applications, you do not have to invest double time, effort, and amount to create one app which is to be implemented on two different operating systems.

Many solutions have been created to deal with these scenarios but two attracted most of the audience - React Native made by Facebook and Flutter made by Google.

These two platforms have their own pros and cons which gives them an edge over others.

Flutter and React Native allow developers to build cross-platform applications by using a single programming language. React Native has been in the market much longer. As compared to Flutter due to which this platform is a lot more matured and has developed its own community and fan base.

React Native by Facebook

Facebook's product, React Native is a lot more mature as compared to other choices such as Ionic, Xamarin, PhoneGap, etc. It has a strong community that provides solutions to all sorts of problems.

At this point in time, React Native is renowned as the world champion. This powerful Javascript framework is built using React library which allows you to develop iOS and Android apps using a single codebase.

People actively use it all over the world and most of the organizations made it their premium choice for their mobile applications.

Funny thing is that Facebook started as a hackathon project in 2013, but in 2015 it became public for the masses.

Flutter by Google

Flutter is the cross-platform framework that develops mobile applications by using Dart language.

Both the language and framework are developed by Google and a lot of efforts and time were invested so that desired applications can be created in the easiest way which serves their purpose completely.

In 2017, the initial alpha phase of Flutter was started which makes it a lot younger than React Native.

Though it is new, its features and competency made it a prominent choice in much less time.

Head to Head Comparison between React Native and Flutter

	React Native	Flutter
Programming Language	JavaScript	Dart
Created by	Facebook	Google
Main Structure	Flux and Redux	BLoC
Hot Reload	Supported	Supported
Release Date	Jan 2015	May 2017
Performance	Native-like	Native-like
Code Reusability	Up to 90%	Up to 90%
Major Use Cases	Facebook Pinterest Instagram	Alibaba Groupon Google Ads

Pros and Cons

We will be having a look on a few advantages and disadvantages which (I hope) allow you to make a wise and calculated decision.

Both the platforms are strong enough to be used, but there are certain features that may work better for you while others need to be considered before you will make your decision in that regard.

	React Native	Flutter
Pros	Having a hot reload feature allows it to have fast coding. One codebase for two mobile platforms Use known and widely used language - Javascript Facilitates to reuse the code and save cost Mature platform Supported by an active and vast community Easy to learn and adapt Less Testing Robust Performance	Hot reload which means fast coding Requires one codebase for two different platforms Requires 50% less testing User-friendly designs Faster app/product development Less Cod Ideal for MVPs
Cons	Limited freedom of choice for the developer UI is fragile Apps require additional coding than the native ones Abandoned packages and libraries Not native	The risk involved in the platform The limited size of the developer community Libraries and support is limited as compared to React Native Requires continuous integration support Size of the App

Performance of React Native and Flutter

While talking about cross-platform applications, their performance and User-interface is considered as the biggest challenge.

You have to provide a seamless experience which the user has while using the native application.

While working around the platform of your choice, developers need to make sure that their product provides quick performance, pixel perfect design, and intuitive navigation.

If you are using Google’s platform or Facebook’s you need to consider the efficiency of how you communicate with the native modules.

In the case of React Native development, the app’s performance slows down as JavaScript needs to bridge, in order to carry out the functions, while in Flutter, Dart is built with necessary components that give immediate access.

We can clearly see that Flutter has an edge in providing a sharp performance to its users.

UI and UX

Most of the effectiveness of these platforms depend upon their user interface design and how things are made easy for the users and developers with the additional features provided.

Flutter provides its own sets of widgets which allows it to implement the design of certain platforms or to customize them easily.

While React Native only uses native UI controllers, though it has an additional ReactJS library which is also rich in UI elements. If you remove this library from the platform then you leave React Native with almost zero UI elements at our disposal.

So, in the case of UI and UX, Flutter is surely winning the game.

Learning Curve

React Native is based on Javascript which is known by the masses whereas Flutter incorporates Dart which is relatively new and has a limited set of developers as compared to the former one.

Mobile developers can easily master JS and develop the desired product in a relatively less amount of time. Finding a programmer for the project would also be much easier as the talent pool is vast.

React Native also supports the massive collection of libraries and ready-made components which make the job a lot more easy. More than that, the reusability of React Native components makes you save a lot of time during the execution phase, and shorten your product time-to-market.

According to this aspect, RN scores the point.

Conclusion

It is clearly stated that React Native is more popular and widely used due to its feasibility and extensive support, but it does not mean that Flutter lags behind.

Flutter is new as compared to RN but soon it is may going to make the buzz due to its features and efficiency.

React Native is currently more stable but we can surely see the growth curve of Flutter too, it is simply a matter of time when both these platforms will have their own significant set of audiences.

These both are ideal choices to develop applications in a timely manner while being cost-effective solutions.

Every application requires different points to be considered, so the decision entirely depends upon the organization and the developer.

At this point of time, no one can predict the future regarding the winner but we can wait and watch how things turn and which platform provides more competent solutions to the problems.