Framer Motion is now Motion: what it means for exported Framer sites

Framer Motion, the React animation library, now goes by Motion and is published as the motion npm package. For React you import it from motion/react instead of framer-motion; the components, hooks and props are the same API. For a Framer site converted to code, this means the project depends on motion, not framer-motion, and every animation, including the site's own code components that imported framer-motion, runs on motion/react.

This post explains the rename, how it shows up in a converted project, and how to move your own code across. Deframer is an independent tool and is not affiliated with, endorsed or sponsored by Framer, and it converts only sites you own or have permission to convert. Motion is an independent open-source project; this post describes it only as far as converted sites use it.

What happened to Framer Motion?

Framer Motion started as the animation library behind Framer and became one of the most used animation libraries for React. In late 2024 it became an independent project under the name Motion, with its own site, and the main package became motion. The library also grew beyond React, with a vanilla JavaScript API, so the old name no longer described it.

In practical terms:

The framer-motion package is still published, so older projects keep working. New code should use motion.

Does Framer still use it?

Framer sites run React and animate with this library; a published site's code includes it. That is why a converted site can keep its animations faithfully: the appear effects, hover states, variants and page transitions were already written against this API. The conversion doesn't translate animations into a different library; it moves them onto the current package.

How a converted Framer site uses motion

When Deframer converts a published site, to Next.js or any of the other four frameworks, the project gets:

• motion in package.json, pinned to one exact version, next to react and react-dom. There's no framer-motion dependency.
• Generated code that imports from motion/react. Components use motion elements such as <motion.div> and <motion.a>, with transitions written out. A spring keeps its stiffness, damping and mass.
• A small kit in src/lib/deframer, imported as @/deframer, that plays Framer-specific behaviours (appear effects, scroll effects, variants, page transitions) on top of motion. It's an original, readable kit, not Framer's runtime.
• The site's own code rewritten to the new package. If a code component or override imported framer-motion, the import is changed to the matching motion entry.

The mapping the converter applies to the site's own imports:

The project pins one version of motion that the kit is written against, so a code component that was written for an older Framer Motion version runs on that version instead. Because the API kept its names, this rarely matters, but it's worth knowing if a component relied on a behaviour that changed between versions.

What carries over and how to edit it is covered in Framer animations and scroll effects in Next.js with motion. This post is about the package.

Migrating your own code from framer-motion to motion

If you've written new components in the converted project, or you're bringing in code from another project that still uses framer-motion, the move is mostly a find and replace:

1. Make sure motion is in package.json (it is, in a converted project).
2. Replace imports:

   - import { motion, AnimatePresence } from "framer-motion";
   + import { motion, AnimatePresence } from "motion/react";

3. Remove framer-motion from package.json once nothing imports it:

   grep -rn "framer-motion" src || npm uninstall framer-motion

4. Run the type checker and the site:

   npx tsc --noEmit
   npm run dev

Keep to one package. Having both framer-motion and motion installed means two copies of the library in the bundle, and components from one won't share context, such as MotionConfig or LayoutGroup, with the other.

Server components and "use client"

In Next.js's App Router, components are server components by default. Motion components need the browser, so a file that renders <motion.div> or uses motion hooks needs "use client" at the top, or must import from motion/react-client, which exports motion elements that work from server components. The converted project already marks the files that need it; follow the same pattern in new code. TanStack Start, React Router, Astro islands and Vite render on the client after hydration, but SSR still applies, so the same care about browser-only code holds.

Updating motion

The version is pinned so the first build matches what was converted. Update it like any dependency:

1. Read Motion's changelog for the versions in between.
2. Update on a branch: npm install motion@<version>.
3. Check pages with heavy animation at three widths, and run visual regression tests with reduced motion off for a manual pass on timing.
4. Check the kit in src/lib/deframer still builds; it imports from motion/react too.

Minor updates are usually quiet. Treat major versions as their own task.

Should you drop motion for CSS animations?

Some teams want fewer dependencies. Simple hover states and fades can be CSS transitions, and many converted components already express variant differences as CSS module classes. But springs, scroll-linked transforms, layout animations and exit animations are what motion does well, and they're what made the Framer site feel the way it does. Replacing them is a redesign decision, not a cleanup. If performance is the concern, measure first; performance tuning a converted Framer site covers where time actually goes.