Migrate from Figma to Penpot

How to migrate from Figma to Penpot without losing the design system

Moving design files from Figma to a self-hosted Penpot instance is an export, import and verification exercise, and anything the exporter does not carry has to be rebuilt by hand. The design systems lead usually owns the work, with platform engineers standing up the Penpot server and a security or IT owner signing off on where the files will live. The Penpot Figma exporter plugin is the starting point. It is maintained by Kaleidos under the MPL-2.0 license and converts a Figma file into a .zip archive that Penpot can import. Its README states that it does not support prototyping settings, so flows and interactions must be recreated or documented separately.

Effort and risk depend on how much of the design system lives in component libraries, variants, auto layout and shared text styles, and on how many files a team has to move. Run a pilot on one representative library before committing to the full set. Check that components, variants, auto layout, text and color styles come through with their structure intact, then compare a few screens side by side against the Figma originals. Confirm with the plugin's current documentation which library links and nested instances survive the conversion, because those are the details most likely to break a shared library. Large files should be split or exported in batches so a failed import is easy to isolate and repeat.

Plan the cutover around the people who depend on the library. Keep the Figma file read-only once its Penpot copy is verified, and record which component names or IDs changed so developers and writers are not surprised. The Penpot GitHub repository lists the project's source and open issues, which is the natural place to check known exporter limitations before the pilot. Ask your hosting owner to confirm backups for the PostgreSQL database and the object storage that holds uploaded assets, since those are the parts of the Penpot instance that carry design data after the migration.

Which Figma capabilities convert cleanly to Penpot and which need rework

This table maps the main Figma capabilities to their closest Penpot equivalent and marks each as clean, needs rework or gap. Penpot works with open formats such as SVG, CSS, HTML and JSON and has native design tokens, but the Figma exporter does not carry prototyping settings. Confirm component, variant and auto layout fidelity on your own files during the pilot rather than assuming it.

Figma capability	Penpot equivalent or outcome	Status
Components and variants	Penpot components and variant sets, which the exporter converts and may need restructuring	Clean, verify in pilot
Auto layout	Penpot flex layout, which covers many common setups but may not match every Figma setting	Needs rework
Libraries	Penpot shared libraries, which must be published and linked again in the target team	Needs rework
Text and fonts	Text layers convert, but fonts must be installed or substituted on the self-hosted instance	Needs rework
Prototyping settings	The exporter does not support prototyping settings, so flows must be rebuilt in another tool	Gap
Comments	Comment threads are outside the exporter's scope, so confirm what carries over and plan to re-create open threads	Gap, confirm in pilot
Version history	Figma history stays in Figma, and Penpot history starts when the imported file is first saved	Gap
Plugins	Penpot has its own plugin system, so Figma plugins must be replaced or rebuilt	Gap
Team permissions	Penpot teams and roles must be set up again in the self-hosted instance, mapped to your identity groups	Needs rework

What to export from Figma and what to rebuild in Penpot

Figma files do not move in one step. Some content comes across through the Penpot exporter plugin, some stays behind in Figma, and some needs a separate archive. The cards below separate those groups so the migration team can plan each one before cutover.

Penpot exporter plugin output

The Penpot exporter plugin converts a Figma file into a .zip that Penpot can import. It is the main path for moving pages, layers, components and styles into a self-hosted Penpot instance. Run it on a copy of each file first, then open the result in Penpot and compare frame counts, component instances and text against the original. Record which files failed or needed a second pass so the rebuild list is complete.

Local .fig, .jam and .deck copies

Figma saves local copies as .fig, .jam or .deck files. These copies hold the design content but carry no version history or comments, and Figma describes the formats as proprietary and subject to change. Treat them as a backup of the file's state at export time, not as a migration format. Keep them in the archive for recovery, and do not expect Penpot to import them directly.

Figma APIs for tooling

Figma points to its official REST and plugin APIs for teams that need to script bulk exports, list files or pull metadata. Use them to build an inventory of every file, project and team library before migration starts. Confirm with Figma which API scopes your plan and admin role allow, since access to some files depends on team permissions.

Team libraries and shared components

Shared libraries in Figma are linked to other files, so a component can break when its source library is not migrated alongside it. Export each library as its own Penpot file, then check that instances in consuming files still resolve to the correct master. Plan the order of imports so that library files exist before the files that depend on them.

Identity and login in Penpot

Self-hosted Penpot supports email and password login by default, plus Google, GitHub and GitLab OAuth, generic OpenID Connect and LDAP. Decide before import which method your designers will use, because accounts and file ownership depend on it. Confirm the exact settings in the configuration guide and test a login with a non-admin account before inviting the team.

Plugins and comments to replace or archive

Figma plugins do not carry over, and Penpot's exporter does not handle prototyping settings. List every plugin used by each team, then find a Penpot plugin or a manual replacement for each one. Comments and version history also stay in Figma, so export or screenshot the threads that matter for audit or handoff and store them in your own archive.

Migration sequence from inventory to decommissioning Figma

This sequence moves Figma design work to self-hosted Penpot in controlled stages, so each stage produces evidence that the next one depends on. The team ends with a verified Penpot workspace, a documented fidelity record and an archive of Figma files that remains readable after the subscription ends.

Inventory files, libraries and plugins
The design lead and an admin list every Figma team, project and file, and mark which files are shared libraries, which are in active product work and which are archived. They also record every plugin in use, the fonts each file depends on and the people who hold edit, view and admin rights. The output is a written inventory with an owner and a migration decision for each file. Do not move on until every file has a named owner and a disposition, because later steps rely on this list being complete.
Select and classify pilot files
From the inventory, the team picks a small set of representative files: one shared component library, one screen flow that uses auto layout and variants, one file with heavy text styling, and one large file that the team expects to be the hardest case. Each file is tagged with the features it uses so the pilot covers the cases that matter. The output is a short pilot list with the reason each file was chosen. Anything Figma prototyping settings control is noted now, because those settings will not come across.
Run pilot imports and sign off fidelity
An admin installs Penpot's Figma exporter plugin, exports each pilot file as a .zip, and imports it into the test Penpot instance. A designer who knows the source file compares components, variants, auto layout, text, fonts and library links against the original, and logs every difference with a screenshot. Large files are split or simplified only after the team has recorded what caused the slowdown. The output is a signed fidelity record for each pilot file, listing what converted cleanly, what changed and what needs rebuilding by hand.
Set up identity and the production instance
The platform team deploys the production Penpot instance in the organization's own environment, with PostgreSQL as the database and an object store for uploads. They configure the chosen login method, such as LDAP or generic OpenID Connect, and confirm that team membership maps to the access model the design leads approved. Backups and a restore test are run before any real file is moved. The output is a working instance with a documented restore result and a list of accounts provisioned from the identity source.
Run a parallel period with both tools
Designers keep working in Figma on active files while the migrated copies run in Penpot for a period the design lead agrees in advance. Each team records which tool is the source of truth for each file, and any change made in one tool is repeated in the other or flagged for re-import. Issues from the pilot are checked against the parallel copies to confirm the fixes hold. The output is an issue log with every gap closed or accepted, and a confirmed list of files each team is ready to move.
Cut over libraries and team access
The team republishes shared libraries from Penpot, updates the library references in each consuming file, and then removes the Figma editors from the moved projects. Designers are given their Penpot roles and a short guide covering what changed in component and variant handling. Figma files are set to view only and left in place until the decommissioning step. The output is a cutover checklist signed by the design lead, showing every library republished and every consumer file re-linked.
Archive Figma and decommission
Before any Figma subscription or seat is reduced, the admin saves local copies of every file that must be kept, which Figma provides as .fig, .jam or .deck files. These copies do not include version history or comments, so the team also exports comments and a record of key versions where they matter. The archive is stored on the organization's own servers with an index that maps each file to its new Penpot location. The output is a verified archive with a checksum list and a written confirmation from the owner of each file.

How large Figma files change the import plan

Large Figma files need a split plan before anyone runs the exporter. The size of a file is not only a matter of how many frames it holds. Page count, the number of library dependencies a file pulls from other files, and the volume of embedded images and custom fonts all add to export time, to the size of the resulting .zip that Penpot imports, and to the number of fidelity checks a team has to run afterward. A file with dozens of pages of screens that each reference the same design system will be heavier and slower to move than its visible content suggests. Before scheduling, inventory each candidate file by page count, image-heavy frames and the libraries it consumes, and treat the heaviest files as their own migration batch. For design systems, split the work into library files and consumer files. Move the library first, so that its components, variants, styles and design tokens exist in Penpot as the single source, then move the product files that use them. Exporting a consumer file that depends on a library which has not been migrated risks broken component instances and a longer manual repair pass. Keep a written list of which library files each consumer file depends on, and confirm with the exporter's behavior on that dependency structure in the penpot-exporter-figma-plugin repository before you commit to a sequence.

Test performance on your own instance before the production run. Stand up a Penpot environment with the same PostgreSQL version, the same Valkey setup and the same storage backend you plan to use in production, whether that is the filesystem or S3-compatible storage such as MinIO. Import a representative large file, a copy of your heaviest consumer file and your largest library, then record how long the import takes, how much storage the uploaded assets consume and whether thumbnails and images load promptly for a second user. Storage latency and object store throughput often matter more than CPU for image-heavy files, so the test should reflect the backend you will actually run. Note the Penpot release you test against, because behavior can change between releases. Treat the exporter's limits as an open question until you have confirmed them. The plugin's documentation does not give a supported maximum file size, page count or asset count in the sources available to this page, so ask the plugin maintainers or check the repository for known issues with large or deeply nested files before you schedule a migration window. Plan a fidelity review for every large file, and budget a second pass for files that fail or import partially. If the test import shows slow or incomplete results, split the file further before the production run rather than forcing it through in one batch.

What drives the cost and duration of a Figma to Penpot move

This table lists the cost components of a move and the drivers that push each one up or down. Use it to see where effort concentrates and what belongs in a written scope before you ask for a quote.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it
Design rebuild of components and variants	Internal design team, sometimes with an external specialist	One-time	Share of files that use variants, nested components and auto layout, since these need manual checking after conversion
Platform engineering for PostgreSQL, Valkey and object storage	Internal platform team or DeployOpen under a fixed scope	One-time setup, then recurring operations	Hosting model, backup design, and whether storage uses the filesystem or an S3-compatible store such as MinIO
TLS, reverse proxy and SSO integration	Internal security or identity team	One-time, with periodic certificate and client renewals	Number of identity sources, whether OpenID Connect or LDAP is used, and how many user groups must map to roles
Fidelity testing after import	Design leads and QA reviewers	One-time per migration wave	File count, number of plugin-generated elements and prototype flows that must be recreated by hand
Training and change management	Design team, product managers and support staff	One-time, with onboarding for new hires	Number of editors, how many shared libraries teams must adopt, and whether Figma habits need to change
Ongoing hosting and upgrades	Platform team or a support retainer	Recurring	Release cadence of Penpot, patching windows, and whether the instance is air-gapped or internet connected
Plugin replacement	Developers or the design team	One-time per plugin	How many Figma plugins the team depends on and whether an equivalent Penpot plugin or API script exists

How the migration differs for small teams, design systems and regulated groups

A small product team with a few dozen files usually has one or two people who own the design workspace and a short list of active projects. The main work is deciding which files move, exporting them in small batches, and checking each one before the Figma copy is retired. Because the file count is low, a single-node deployment is often enough to start, and Docker Compose is the simplest hosting path to test first. Identity can stay simple at the start with email and password login, then move to OpenID Connect or a Git-based OAuth provider once the team is settled.

Sequencing: Export and import one project at a time, starting with the file that has the fewest dependencies on shared libraries.
Hosting: Use Docker Compose on one server with PostgreSQL and the object storage Penpot needs, and confirm the current setup steps in the technical guide.
Identity: Start with local accounts for a pilot, then add single sign-on before inviting the wider team.
Parallel running: Keep the Figma files read-only for a short overlap period so designers can compare results without losing work.
Backups: Schedule database and object storage backups from day one, since a single server is also a single point of failure.

Before retiring any Figma file, confirm that comments, prototype links and fonts were reviewed by the designers who own them.

How to check fidelity after importing Figma files into Penpot

The fidelity check starts before anyone opens the imported file. Export a short inventory from each Figma source file: the number of top-level frames, the count of component instances, the list of component sets and their variant properties, and the text styles in use. Record the same counts for the Penpot import. Where a count differs, trace the difference to a specific frame before accepting it. Compare auto layout by selecting a sample of frames with nested auto layout and resizing them, because the spacing, padding and wrap behavior is where converted layouts most often drift. Then check fonts. Confirm that every font used in Figma is either available in the Penpot instance or replaced deliberately, and that the substitution is written down, since a silent fallback changes line breaks across every screen.

Image assets need their own pass. Check that each image fill, mask and placed bitmap renders at the expected size and crop, and that no asset is missing from the import. Designers should then review key screens at each breakpoint the product supports, comparing the Penpot render against the Figma original side by side. Prioritize the screens that customers and internal teams use most, plus any screen with a component that has many variants. Use a fixed review sheet so reviewers record the same fields each time. Treat anything that does not match as a defect with an owner, not a note for later.

Two things will not come across and must be handled as project work. Prototyping flows do not survive the exporter, which does not support prototyping settings, so document every flow (trigger, destination, transition and any interaction logic) from Figma and rebuild it using the prototyping approach your team adopts in Penpot. Comments and version history also stay behind. Archive them from Figma before cutover, and confirm the current penpot-exporter-figma-plugin repository notes on supported elements for the version you run, because scope changes between releases. Keep the Figma files read-only once the final import is signed off, so no edits land in the source after the comparison.

What usually goes wrong in a Figma to Penpot migration and how to prevent it

Most failed design migrations break in predictable places: fonts, component links, plugins, prototypes, login and infrastructure sizing. Each risk below pairs with a prevention step that a pilot, inventory or staging test can confirm before the cutover date is set.

Text reflows after import

When a font used in a Figma file is not installed or licensed on the Penpot side, text falls back to a substitute face and line breaks move, which breaks layouts that were tuned by hand. Text is one of the areas where fidelity is most visible to reviewers. Before import, export a font inventory from every file in scope, confirm which faces the organization licenses for web use, and make sure those files are available to the Penpot instance. Then check text-heavy frames in the pilot sign-off.

Component links break after import

Instances can detach from their main components, or variants can flatten, when the library is not imported with its source files. Design systems depend on those links, so a broken instance changes every screen that uses it. Import the shared library first, confirm the instance count per component matches the source, and test a sample of variant sets on both sides before the team edits production files.

Plugin-dependent workflows stop

Designers and developers often rely on Figma plugins for icons, content, spacing checks or export naming. Penpot has its own plugin system, so a plugin with no equivalent quietly disappears from the daily routine. Build a replacement list that maps each plugin in use to a Penpot plugin or a manual step, and assign an owner to every gap before the cutover.

Prototype flows lost without a record

The Penpot Figma exporter does not support prototyping settings, so click paths, transitions and overlay behavior will not arrive in Penpot. Teams that present flows to stakeholders can lose that work without noticing. Before export, document every prototype flow as screen-to-screen diagrams or recordings, store them with the migrated project, and agree with product owners which flows must be rebuilt.

Identity mismatches during SSO setup

Self-hosted Penpot supports email and password login by default, plus OAuth providers and generic OpenID Connect or LDAP. A user whose email claim, username or group attribute differs from the identity provider can end up with a second account, and that account will not see the migrated files. Run a login test in staging with a representative group of users, confirm the claims Penpot receives, and decide in advance how existing accounts map to the new ones.

Undersized PostgreSQL or storage

Penpot supports only PostgreSQL, recommending version 13 or later, and it stores uploaded objects on the filesystem or in S3-compatible storage such as MinIO. Large Figma files with many images can push both past a capacity assumed during setup. Ask the implementation partner for a capacity test that imports the largest files in scope, measures database growth and storage use, and confirms backup restores work before users arrive.

Cutover before designers are trained

Penpot's interface, component model and shortcuts differ from Figma's, so a cutover without training slows delivery even when every file imported cleanly. Schedule a training window before the switch, run designers through their own files on the pilot instance, and keep Figma read-only for a defined period so teams can look up anything the migration missed.

Questions buyers ask before moving Figma files to Penpot

How much does a Figma to Penpot migration cost?

The cost depends on the size and structure of your design estate, and most of it is labor rather than software. Penpot's self-hosted edition carries no license fee, so the one-time items are the migration work itself, the review of converted files and any rebuilding of components or libraries that do not carry over cleanly. The recurring items are the servers, PostgreSQL, Valkey and object storage you run, plus the staff time to operate them. Penpot's cloud pricing page lists Professional at $0, Unlimited at $7 per editor per month capped at $175 per month, Enterprise at $25 per member per month and a Private Server at $50k per year, as read in October 2026, if you compare hosted options. When you request a quote, ask for the file inventory, the expected rebuild effort per library and a written list of what is excluded.

How long does moving Figma files to Penpot take?

Timing is set by the number of files, the number of shared libraries, how many components use variants and auto layout, and how many people must review the results. Large files take longer to export and import, and each library that depends on others needs to be checked after conversion. Your team's availability for sign-off also sets the pace, because design owners need to confirm that spacing, typography and component behavior match the originals. Ask any provider for a schedule tied to a written scope, with a pilot batch of representative files before the full migration starts.

What does the migration need from the design and IT teams?

Design teams need to nominate owners for each library, list which files are live products, and agree which pages, comments and version history they need to keep. IT teams need to provision the Penpot host, PostgreSQL 13 or later, Valkey, storage (filesystem or S3-compatible, such as MinIO), TLS certificates and the login method, which can be email and password, Google, GitHub or GitLab OAuth, generic OpenID Connect or LDAP. Both teams should agree on backup and restore procedures before anyone imports production files.

Can an internal team migrate Figma files to Penpot without help?

Yes, a team with design and platform skills can run a small migration on its own, provided it has someone who can run Docker Compose or Helm, manage PostgreSQL backups and work through the exporter's output. The Penpot Figma exporter plugin is maintained by Kaleidos under MPL-2.0 and converts Figma files into a .zip that Penpot imports. Larger estates usually benefit from outside help with batch planning, conversion review, library rebuilding and documentation. Whichever route you choose, confirm the plugin version and Penpot release in use, and test with copies before touching production.

Do prototyping flows have to be rebuilt in Penpot?

Yes, plan to rebuild them. The Penpot Figma exporter plugin does not support prototyping settings, so click-through links, overlays and interaction triggers will not carry over. Static screens, components, variants, auto layout, text styles and libraries are the parts to verify. Ask for an inventory of every prototype flow before the migration, so you can decide which ones to rebuild in Penpot's interaction features, which to retire and which to keep in Figma until the rebuild is complete.

What happens to comments and version history during migration?

Plan on the assumption that comments and Figma version history will not come across through the exporter, so export the discussion you need to keep before you start. Figma's local copies in .fig, .jam or .deck formats carry no version history or comments either, and Figma describes those formats as proprietary and subject to change. Record the decisions and open review threads in your own system, and keep archived Figma files available read-only for the period your audit or product team requires.

How do we confirm the migrated design matches the original?

Confirm fidelity with a written checklist that compares named screens, components, variants, auto layout behavior, text styles, color styles, component instances and library links. Pick representative frames from each product area, export them from both tools and review the differences with the original designers. Check nested components, font substitution and image handling, since these often change silently. Keep a signed acceptance record per file so the design owner, not only the migrator, approves the result.

Does a migration need a security review of the new Penpot host?

Yes, the host holds your design files, accounts and uploaded assets, so treat it like any internal application. Review the login method, access to the database and object storage, backup encryption, retention for deleted files and who can administer the instance. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your own infrastructure, and prepares systems and evidence for compliance assessments. It does not issue audit reports or certifications, which independent auditors and certification bodies provide.

How DeployOpen scopes and runs a Figma to Penpot migration

DeployOpen plans and implements self-hosted open-source platforms inside the client's own infrastructure, and runs this migration as a fixed-scope engagement with the scope agreed in writing before work starts. The work covers the Penpot deployment, the Figma export and import path, fidelity checks and handover documentation.

How we scope

Inventory which Figma files, libraries and team projects are in the move, with owners and open editing dependencies.
Agree in writing which features convert, which need manual rebuilding, and which prototyping behavior is out of scope.
Confirm the target hosting, PostgreSQL, storage and login method, including whether SSO or LDAP is required.

How we build

Deploy Penpot in your environment with Docker Compose or the official Helm chart, sized to the agreed file set.
Run the Penpot Figma exporter plugin on a test set first, then split large files and record conversion results.
Test fidelity on components, variants, auto layout, text and library links against the original Figma files.

How we hand over

Document the import runbook, known conversion gaps and the rebuild list for prototyping interactions.
Provide a signed-off fidelity log that maps each source file to its Penpot counterpart and any open issues.
Train designated owners on library publishing, access rules and routine updates in your own environment.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the initial handover.
Keep backups and restore tests for the Penpot database and object storage on the schedule you approve.
Review each Penpot release for compatibility with your plugins, login setup and deployment before upgrading.