We recently migrated our website from a Prismic and Next.js stack to Framer. Not because Prismic was broken. It served us well. But the way we worked around it was slowing us down. Every design change required a developer. Every layout tweak meant a deploy cycle. The gap between what we designed and what shipped was always wider than it needed to be. Framer closed that gap.

Speed of iteration changed everything

With Prismic, updating a section on the homepage meant opening the codebase, finding the right slice component, adjusting styles or markup, pushing to a branch, waiting for a preview deploy, reviewing, merging, and deploying to production. All of that for a spacing change. The tooling was solid, but there were too many steps between an idea and a live result.

In Framer, that same change takes seconds. Select the element, adjust the value, publish. Done.

This isn't just convenience. It fundamentally changes how you work. When shipping is that cheap, you iterate more. You try three layout variations instead of committing to one because rework is expensive. You fine tune spacing, swap type hierarchies, test different visual weights. All on the live site, all in real time. The design process doesn't stop at the handoff. It continues all the way through to production.

For our team, turnaround on page updates went from days to hours. New landing pages that used to take a full sprint now ship in a single focused session.

Design flexibility without compromise

One of our concerns going in was whether Framer would feel limiting coming from a fully custom frontend. It didn't.

Framer gives you real CSS layout under the hood. Flexbox and grid, exposed through a visual interface that doesn't dumb it down. You get full control over alignment, distribution, wrapping, gap, and overflow. Stacks, which are Framer's primary layout primitive, map directly to flex containers. Once you understand that mental model, you can build anything you'd build in code.

We leaned into modern layout patterns throughout the rebuild. Consistent use of auto layout with gap based spacing instead of margin hacks. Proper grid structures for content heavy sections. Container based sizing that scales predictably across breakpoints. The result feels intentional and systematic in a way that's hard to maintain when design and code live in separate tools.

What surprised us most was how much creative freedom we actually gained. Without the overhead of dev implementation, we explored more ambitious layouts. Overlapping elements, layered scroll interactions, dynamic grids. Things we would have deprioritized in the old stack because the build cost didn't justify the design payoff.

Rem based sizing for a scalable system

Early in the rebuild we made the decision to use rems as our primary unit instead of pixels. Framer supports rem values throughout typography, spacing, and sizing. It made a noticeable difference in how the design scales.

With rems, the entire system is proportional. Base font size drives everything, so the relationship between type, spacing, and component sizing stays consistent regardless of context. It also made responsive adjustments cleaner. Instead of overriding dozens of pixel values per breakpoint, we could adjust the base scale and let proportions do the work.

This is a small technical choice that had an outsized impact on design consistency. Everything just felt more cohesive once we committed to it.

Responsive design that doesn't feel like a chore

Responsive work in a Prismic and Next.js setup meant writing media queries, testing in dev tools, adjusting, rebuilding, and retesting. It worked, but it was tedious and completely disconnected from the design process.

Framer's breakpoint system makes responsiveness visual and immediate. You design the desktop layout, drop to the tablet breakpoint, adjust what needs adjusting, drop to mobile, and adjust again. Changes cascade downward, desktop first, so you're only overriding what actually changes at smaller sizes.

You can drag the canvas width in real time and watch your layout respond. No browser refresh, no guesswork. If something breaks at an awkward width, you see it instantly and fix it on the spot.

For our team this turned responsive design from a late stage QA task into a natural part of the design process. We caught and resolved layout issues earlier, and the final result across devices was tighter than anything we'd shipped with the old stack.

Custom code components and overrides

Framer's visual builder covers the majority of what a marketing site needs. But for anything beyond that, like dynamic data, third party integrations, or custom interactions, you write code components and overrides in React.

Code components are full React components that live inside Framer's canvas alongside visual elements. They can accept props exposed as controls in the properties panel, fetch external data, manage internal state, and render anything React can render. For us, this covered things like custom form handlers, animated counters, dynamic filtering, and API driven content blocks.

Overrides are lighter. They're functions that attach to any visual element on the canvas and modify its behavior. Need a scroll triggered class toggle? An override. Cursor following parallax on a specific image? An override. They're perfect for adding interactivity to visually designed elements without rebuilding them in code.

The balance works well. You design visually by default and reach for code only when the visual tools run out. And because both systems use React, there's no context switch. It's the same component model, same mental framework.

301 redirects and no broken links

One of the non negotiable requirements for the migration was preserving every existing URL. We had indexed pages, backlinks, shared links across socials and emails, and documentation pointing to specific paths. Losing any of that wasn't an option.

Framer handles this cleanly through its built in redirect settings. We mapped every old URL from the Prismic site to its new Framer equivalent with 301 permanent redirects. Blog post slugs, landing pages, resource links, legal pages. All accounted for.

The setup was straightforward. A flat list of from and to paths in Framer's project settings. For sites with a large number of redirects, you can prepare the mapping in a spreadsheet and add them in bulk. We verified every redirect with a crawler after launch to make sure nothing slipped through.

Search rankings held steady through the transition. No 404 spikes, no lost referral traffic. This was one of the smoothest parts of the entire migration.

Blog and CMS were transferred manually

We didn't attempt to automate the content migration. Our blog posts, case studies, and other CMS content were transferred by hand from Prismic into Framer's built in CMS.

This was deliberate. Prismic's content model was built around slices, which are modular content blocks that could be assembled in flexible combinations. Framer's CMS is simpler and flatter, with collections made up of typed fields. Rather than trying to force one structure into the other, we used the migration as an opportunity to audit and clean up our content.

We reviewed every post. Some were outdated and got archived instead of migrated. Others needed updated copy, better images, or revised metadata. By the time we finished, the content in Framer's CMS was leaner and more intentional than what we had in Prismic.

Framer's CMS itself is easy to work with. You define a collection, add fields like title, slug, cover image, author, date, body, and tags, and then bind those fields to visual components on the canvas. The design of the blog template is fully in your control. Same visual tools as every other page. No separate theme layer or template engine to wrestle with.

For our content volume, manual transfer took about a week. Larger content libraries would take proportionally longer, but the cleanup value made it worthwhile.

Maintainable and scalable without needing a developer

This is probably the most underrated part of the move. With Prismic and Next.js, even small content or layout updates often needed someone comfortable with code. Changing a button label was easy enough in the CMS, but moving a section, swapping out an image with different dimensions, or adjusting how something looked on mobile meant opening the codebase. That created a bottleneck. Every update, no matter how minor, had to wait for a developer to be available.

In Framer, a designer or marketing person can handle most of the day to day updates on their own. Swap out copy, update a blog post, rearrange sections, adjust spacing, publish a new landing page. All of it happens visually, and the interface is forgiving enough that you're not going to accidentally break the site by changing a heading.

That safety net matters. In a code based setup, one wrong edit to a component can cascade across multiple pages. In Framer, changes are scoped to what you're looking at. You see the result before you publish. There's no hidden side effect lurking in a shared stylesheet or a reused template partial.

It also means the site scales better as a team effort. You don't need to onboard someone into a codebase just to let them make content updates. A new team member can start contributing on day one.

We still use code components and overrides for the more complex interactive parts of the site. But those are contained and don't interfere with the parts of the site that non technical team members work on.

What we shipped

The end result is a site that's faster to update, more visually consistent, and easier to maintain. Design decisions are implemented directly with no interpretation layer between intent and output. Responsive behavior is handled as part of the design process, not as an afterthought. The type and spacing system built on rems scales cleanly. Redirects preserved every existing link. Content is cleaner than before.

But the real win is operational. Our team ships faster. We experiment more. We say yes to design ideas that we would have scoped out in the old stack because the implementation was too complex or time consuming. The distance between "what if we tried this" and "it's live" is now measured in minutes, not sprints.