Migrating From XD Is a Rebuild, Not a File Import

"Migrate the file" implies a button that doesn't exist. Figma has never shipped a native Adobe XD importer, and Adobe never opened the XD document format for one — so every path from an .xd file into Figma runs through a third party's best-effort reconstruction of a format neither company documents publicly. That's a different kind of operation than an import. An import is lossless by definition. A reconstruction is lossy by construction, and the loss isn't random: it falls almost entirely on the layers of a file that never had geometry to begin with — what happens when you tap this, which state this component is currently in, what this color is actually called.

That predictability is the useful part. Once you know which category of information a conversion route can carry — shapes, position, fills — and which category it structurally cannot — logic, state, intent — migrating a file stops being a hope that the tool "got it right" and becomes a checklist: verify what should have survived, then rebuild what never could have. This guide works that checklist in the order it actually needs doing, starting with the one step every route below depends on and none of them will do for you.

01Not an import — an inventory

Adobe stopped selling XD as a standalone application to new customers in mid-2023 and moved it into maintenance mode the following year: security and bug fixes only, no new feature development, and as of this writing no announced end-of-life date. Figma's own Help Center documents no procedure for opening an .xd file directly, and Figma's official forum answers the question the same way every time it comes up — there's no built-in feature, you need a third-party tool. Adobe has never published a converter of its own either. Neither company treats this as their problem to solve, which means it's yours.

Before opening any conversion tool, inventory the source file the way you'd document a system you're about to deprecate — because functionally, that's what's happening to it. For every component that has a States panel, screenshot each named state. For every screen with prototype wires, list the trigger type (tap, drag, time, voice, keyboard) and what it connects to. Export or photograph the Assets panel's color list and character styles. None of this is recoverable from a converted file after the fact — the conversion routes below don't preserve it, they simply don't carry it in the first place, and once the XD file itself is archived or the team's Creative Cloud seats lapse, your notes are the only remaining record that any of it ever existed.

02Picking a conversion route

Three practical routes exist, and they trade fidelity against cost in a fairly predictable way. None of them is complete, and testing a sample file before committing an entire library to one is always worth the hour it costs.

The practical rule of thumb: for a handful of files, manually exporting as SVG and rebuilding by hand is often faster than debugging what a converter got subtly wrong. For a genuinely large library, a plugin or paid first pass is worth it specifically to save the redrawing labor — but budget real time for the rebuild work in every section below regardless of which route gets the shapes across. No route changes what happens after the shapes land.

03Repeat Grid becomes Auto Layout, not a checkbox

XD's Repeat Grid takes a selected group and tiles duplicate copies at a fixed padding. It's a duplication tool, not a layout algorithm — it has no concept of Hug, Fill, or Fixed resizing, no gap that resolves dynamically against a sibling's content, and no wrapping behavior beyond whatever was true at the moment the grid was created. It stores a snapshot of a tiled arrangement, not the rules that produced it.

No conversion route reconstructs Auto Layout properties from a Repeat Grid, because a Repeat Grid never stored the intent data Auto Layout needs — direction, per-axis resizing, gap as a relationship rather than a measured distance. Every route delivers the tiled instances as individually positioned, static copies. Rebuilding means starting over with the container, not adjusting what came through:

• Identify the direction the repeat actually represents — a row of cards, a column of list items — and recreate the container as a Figma frame with Auto Layout set to that direction.
• Set gap to match the visual spacing in the original tiling, measured from the converted (static) copies before you delete them.
• Decide Hug versus Fill per axis based on what the content should do against real data, not against however many tiles the designer happened to have when the grid was built.
• If the repeated item itself has internally stacked content — an icon over a label over a description — nest a second Auto Layout frame inside each instance rather than flattening everything into one container's properties.

04Master components and states become main components and variants

XD's Components panel gives you a master component with downstream instances, and a States feature attached directly to that same component — named states like Default, Hover, or Toggled that get switched via an interaction, without ever being exposed as separate, independently referenceable pieces. Figma's model is structurally different: a main component plus a set of variants, where each named property combination is technically a sibling component grouped into a set, and properties can be typed as boolean, variant, or instance-swap.

Nothing maps this automatically, because XD's states were never declared as typed properties in the first place — they're baked switches on one component, not a property system a converter could read and translate. Rebuilding means working from the state inventory you took in the first section: recreate each state as an explicit Figma variant property (state: default / hover / focus), not as a set of visually similar but separately named frames that happen to look right. A duplicate frame that isn't wired as a variant can't be referenced by instance-swap logic, won't show up correctly in Dev Mode, and won't respond to interactive prototype state changes the way a real variant does.

Per-instance overrides need the same manual attention. If instances of the original XD component had individually swapped text or color, none of the conversion routes reconstruct that override relationship — they treat every visual copy as an independent, flattened layer group with no memory of which master it came from. Once the base component is rebuilt in Figma, each instance's overrides have to be reapplied by hand, checked against the original file or your inventory screenshots.

05Prototyping wires do not transfer

XD's prototype triggers — Tap, Drag, Time, Voice, Keyboard and Gamepad, plus Auto-Animate for smooth cross-artboard transitions — carry zero data through any conversion route. SVG has no concept of interactivity beyond a hyperlink, so a manual export drops wiring entirely. Plugins and paid services that advertise "prototype preservation" typically mean they preserve frame-to-frame hotspot regions at best — not trigger type, not easing, and not Auto-Animate's matched-layer interpolation. Confirm this by actually clicking through the converted file's prototype, not by trusting a feature list.

Figma's closest conceptual analogue to Auto-Animate is Smart Animate, but Smart Animate has a requirement Auto-Animate never enforced: it interpolates properties between two frames by matching layer names, so any layer that should visually transform between states needs an identical name on both sides. Naming discipline that was optional in XD becomes mandatory in Figma, and it needs to be planned before wiring a single transition, not discovered mid-rebuild when a transition simply refuses to animate.

Treat the interaction map as its own spec document, written from the original file's actual flow — screen, trigger, action — before opening Figma's prototype tab at all. Nothing about the converted file will hint that a wire used to exist there; the only reliable source is the inventory taken while the original file was still readable.

06The Assets panel becomes styles and variables

XD's Assets panel holds three flat lists — Colors, Character Styles, Components — each named but untiered. None of the conversion routes recreate Figma Styles or Variables from these lists. Colors typically arrive as raw fill values baked directly onto each shape, with the original name gone entirely. Character styles rarely survive as reusable text styles either; each text layer just keeps its literal font, size, and line-height as a local override with nothing tying it back to a shared definition.

This is unavoidably a rebuild, which is also what makes it worth doing properly rather than reproducing the flat structure exactly as it was. A flat XD color list already carried the ambiguity a name like "Primary Blue" implies — it tells you what the color looks like, not where it's allowed to be used. Since every converted layer needs to be manually reassigned to something anyway, it costs little extra to build a primitive tier (a Variable holding the raw value) with a semantic tier aliased on top of it, rather than paying to redo that restructuring a second time later.

In practice: export or photograph the Assets panel before conversion, the same inventory principle as the first section. Recreate each named color as a Variable and each character style as a Figma text style. Then go through every converted layer and manually reassign it — the converted layers will be sitting on raw local values with no link to anything until that pass is done.

07Plugins and dev specs need Figma-native replacements

XD's plugin API and Figma's plugin API are separate runtimes with separate manifest formats — no XD plugin runs unmodified inside Figma. If a workflow depended on a specific XD plugin for content generation, spec export, or batch renaming, the replacement has to be found or built fresh in Figma's plugin directory. A similarly named plugin on the other platform is not a safe assumption of identical behavior; check what it actually does before relying on it for production work.

XD's Design Specs view — the redlines and measurements panel built for handing work to developers — maps conceptually to Figma's Dev Mode, but Dev Mode is a genuinely different surface: its own inspector, its own code-snippet export, its own annotation tools, entered through a mode toggle rather than a panel that was always sitting open. A developer who worked from XD's spec view for years needs a short, deliberate walkthrough of Dev Mode specifically — "it's the same thing in a new place" undersells how differently the two are structured to use.

08A worked example: one card component, start to finish

A product card component in XD: two named states in its States panel — Default, and Hover, which swaps in a drop shadow and a background tint — with three instances placed on a screen via Repeat Grid, one of which has its title text individually overridden.

The rebuild order follows the sections above in miniature: inventory the two state names and the one override before converting anything; bring the geometry across through whichever route fits the file volume; rebuild the component with state as a real variant property instead of a second detached frame; replace the Repeat Grid with an Auto Layout frame sized to the actual gap; and reapply the single text override by hand, since no route reconstructs which instance it belonged to.

09Cheat sheet

• No conversion route imports behavior — only geometry has a realistic chance of surviving intact. Plan every migration as a rebuild from day one, not a file open that might need minor touch-ups.
• Inventory before converting anything: screenshot every component's states, list every prototype trigger and its target, export the Assets panel. This information disappears the moment the source file is archived — it isn't recoverable from the output of any converter.
• Pick a conversion route by file volume, not by feature claims. A handful of files is often faster to rebuild from a manual SVG export than to debug a plugin's edge cases; a large library justifies paying for a first pass specifically to save redrawing time.
• A Repeat Grid is a duplication tool, not Auto Layout. Recreate direction, gap, and per-axis resizing intent by hand rather than trusting a converted tile grid to behave like a real container.
• States baked into an XD component need to become explicit, named Figma variant properties — a visually similar duplicate frame that isn't wired as a variant won't work with instance-swap logic, Dev Mode, or prototype state changes.
• Prototyping wires carry zero data through any route. Rebuild the interaction map as a spec document first, and expect Smart Animate to require matching layer names that Auto-Animate never enforced.
• Recreate the Assets panel as Figma Styles and Variables, not as raw local values baked onto each shape — and add a semantic tier while the restructuring is already happening anyway.
• Plugins and Adobe's Design Specs view both need Figma-native replacements. Don't assume a similarly named tool on the other platform behaves the same way just because it solves a similar problem.