framer-motion to motion/react: The 2026 Migration Guide

TL;DR. Framer Motion was renamed to motion in v11 (late 2024). The legacy framer-motion package still works in 2026 but is deprecated. The migration is a find-and-replace: change the package name, change from "framer-motion" to from "motion/react", and the rest of your code stays the same. Most codebases land in under an hour.

The minimal migration

# 1. Swap the dependency
npm uninstall framer-motion
npm install motion

# 2. Find-and-replace across your codebase
#    from: "framer-motion"
#    to:   "motion/react"

That is the entire migration for ~90% of projects. The motion package re-exports the same APIs under the same names. Anything you do today with motion.div, AnimatePresence, useScroll, useTransform, useReducedMotion, useAnimationControls continues to work unchanged.

Before and after

A representative component, before:

"use client";

import { motion, useReducedMotion } from "framer-motion";

export function Fade({ children }: { children: React.ReactNode }) {
  const reduce = useReducedMotion();
  return (
    <motion.div
      initial={{ opacity: 0, y: 8 }}
      animate={{ opacity: 1, y: 0 }}
      transition={{ duration: reduce ? 0 : 0.4 }}
    >
      {children}
    </motion.div>
  );
}

After:

"use client";

import { motion, useReducedMotion } from "motion/react";

export function Fade({ children }: { children: React.ReactNode }) {
  const reduce = useReducedMotion();
  return (
    <motion.div
      initial={{ opacity: 0, y: 8 }}
      animate={{ opacity: 1, y: 0 }}
      transition={{ duration: reduce ? 0 : 0.4 }}
    >
      {children}
    </motion.div>
  );
}

One import line changed. The component body is identical. Multiply across your codebase and you have the migration.

What stays identical

What changes meaningfully

The non-obvious differences worth knowing:

• Bundle size. The motion core ships smaller and tree-shakes better. For a marketing page using a handful of components, expect a small KB-level reduction.
• Vanilla JS path. motion ships a vanilla JS entry (motion as opposed to motion/react) for non-React contexts. framer-motion was React-only.
• 3D animation. framer-motion-3d is being subsumed - check the motion docs for the current naming.
• Type names. Some legacy type aliases are soft-deprecated. If you import internal types, audit those.

When to migrate, when to wait

Migrate now if:

• Your project is long-lived (SaaS app, ongoing client work)
• You want the smaller bundle and the cleaner vanilla path
• You are starting a new project today

Wait if:

• You are shipping a one-off marketing page and never touching it again
• You have a hard deadline this week and no test coverage on animation paths
• You use framer-motion-3d heavily - the 3D migration is the only place this is more than a rename

A migration checklist

1. Run your test suite. Note the baseline.
2. npm uninstall framer-motion && npm install motion
3. Global find-and-replace: "framer-motion" → "motion/react". Most editors will scope to string literals only.
4. Run typecheck. Resolve any internal-type imports.
5. Re-run your test suite.
6. Smoke-test the animation-heavy pages by hand.
7. Ship.

shadcn Motion Blocks and the migration

shadcn Motion Blocks currently uses framer-motion: ^12.39.0 - the legacy package name. The blocks themselves use only standard APIs that survive the migration unchanged. If you install a block via the shadcn CLI into a project that uses motion/react, you can swap the import in the installed block file directly - no behavioural change.

Related reading: the 8 animated hero section patterns for shadcn/ui post walks through the motion patterns used across the pack, and the marquee post covers the CSS-vs-JS marquee tradeoff in detail.

FAQ

Do I have to migrate from framer-motion to motion?

Not urgently. The legacy framer-motion package still works in 2026 and is unlikely to break in the short term. But it is deprecated - new features ship under the motion name. If your project is long-lived, migrate. If you ship today and forget it, you can wait.

What changed between framer-motion and motion?

Package name (framer-motion → motion), import path (motion/react instead of framer-motion). The runtime APIs - motion components, useScroll, AnimatePresence, useReducedMotion - are identical for the vast majority of cases. The migration is mostly a find-and-replace.

Does the bundle get smaller after migration?

Slightly, because motion ships a smaller core and tree-shakes better. The exact size depends on what you import. For most marketing-page use cases, the difference is small (a few KB), not transformative.

Will my reduced-motion logic still work?

Yes - useReducedMotion is available unchanged in motion/react. Any prefers-reduced-motion handling you have today carries over without changes.

Can I have both installed during migration?

Technically yes, but you will likely see TypeScript conflicts on the motion components if you import from both. Better to migrate in one PR: rename imports across all files, swap the dependency, run typecheck. For most codebases it is an hour of work.

Does shadcn Motion Blocks use motion or framer-motion?

shadcn Motion Blocks currently uses framer-motion ^12.39.0 - the legacy package name. The migration to motion is straightforward and on the roadmap. The blocks themselves use only standard APIs (motion components, useReducedMotion, useScroll), so any consumer can swap the import path locally without changes to the block code.

What about Framer Motion 3D and other sub-packages?

framer-motion-3d is being folded into motion's 3D offering. Check the motion docs for the current state - this is the place where the migration is meaningfully different rather than a rename.