How to migrate from Lucidchart to draw.io without losing diagrams
Diagrams can move from Lucidchart to draw.io through two documented routes: copying content from Lucidchart into the draw.io online editor, or exporting each document from Lucidchart as VSDX and opening it in draw.io's Visio import. Both routes preserve the shapes and text in most diagrams, but expect rework on layout, connector routing and any interactive content such as links, data-linked shapes or shape data. If a renewal or a data residency requirement is the trigger, treat the migration as a per-diagram review rather than a file conversion, and confirm the current behavior of each route against the draw.io import formats documentation and the Lucidchart import guide before you commit a schedule.
The work is usually shared. Diagram owners know which documents matter, which are stale and which hold shape data or links that someone downstream depends on, so they should decide what moves and check the result. An IT or platform lead owns where the draw.io instance runs, how files are stored and who can open them, and should confirm that the online editor's use fits the residency rule, since draw.io's privacy policy says hosted export and real-time collaboration process diagrams temporarily on Cloudflare servers. An implementation partner is optional and useful when hundreds of diagrams need a repeatable inventory, a self-hosted deployment and a sample review. Ask any partner for the scope, the sample size and the acceptance criteria in writing before work starts.
The main risk is silent loss or drift, not a failed import. Before you start, export a sample of representative diagrams, open them in draw.io and compare them side by side with the originals, paying attention to embedded images, comments and anything that depended on Lucid's interactive behavior. The draw.io documentation on Visio import differences lists known gaps such as embedded EMF images and lost interactivity. Keep the original Lucidchart files available until each diagram has been signed off by its owner, and record which route was used for each file so that any later question about a diagram can be traced.
Which Lucidchart capabilities map cleanly to draw.io
This table compares Lucidchart's main diagramming features with their draw.io equivalents and rates each one as clean, needs rework or gap. Read the status column first, then review every row marked rework, because Visio-origin files may look different and embedded EMF images are not imported. The main takeaway is that standard flowcharts move well, while comments, linked shape data and custom stencils need planning before cutover.
| Lucidchart capability | draw.io equivalent | Migration status |
|---|---|---|
| Shapes and connectors | Native draw.io shapes and connectors, editable after import | Clean for standard flowcharts. Check connector routing and spacing after paste. |
| Lucidchart diagram import | Copy all in Lucidchart, paste into the draw.io online editor | Clean for simple diagrams. Review large or layered diagrams page by page. |
| Visio-style stencils | Imports .vssx and .vss stencils as shape libraries | Needs rework. Rebuild custom Lucid stencils as draw.io libraries and test each shape. |
| Exports to PDF, PNG and SVG | Export from the draw.io editor to PDF, PNG and SVG | Clean. On a self-hosted Docker server, PDF uses the browser print dialog unless an export server is set up. |
| VSDX export into draw.io | Imports .vsdx files, which may look different from the original | Needs rework. Embedded EMF images do not import, and interactive behavior may be lost. |
| Templates | draw.io template library and custom templates stored in your own storage | Needs rework. Organization templates must be recreated and re-tested. |
| Comments and review threads | No direct equivalent in the diagram file | Gap. Export comments separately and confirm what your exports include. |
| Shape data and linked data | Custom properties and placeholders, set up manually after import | Gap. Confirm which shape data survives import before relying on it for reports. |
Copy and paste or VSDX import: choosing a route
Copy and paste is the shorter route. In Lucidchart, you select the content of a page, copy it with the keyboard shortcut, and paste it into the draw.io online editor. draw.io documents this as its Lucidchart import method, so it suits single pages with a moderate number of shapes, labels and connectors that you can check by eye in one sitting.
- Best fit: a single page with standard shapes, text and connectors that you can review immediately after pasting.
- Fast review: you see the result at once and can fix one page at a time without creating an intermediate file.
- Possible losses: anything stored as metadata rather than as visible shapes may not survive the paste. Test one page first and compare it with the original.
- Repeated work: each page is pasted separately, so long multi-page documents mean repeated steps.
- Data path: the editor converts in the browser. draw.io's trust page says diagrams are saved where you choose and never on its servers, but hosted export and real-time collaboration process diagrams temporarily on Cloudflare servers.
Before you rely on paste, compare one converted page side by side with the original and check labels, connector routing and fonts.
The VSDX route uses a file as the handoff. Lucidchart exports individual documents to Visio formats, and draw.io imports .vsdx files. This route suits diagrams that began in Visio or use Visio-style stencils, and multi-page documents you want to handle as files that you can keep and check again later.
- Best fit: diagrams with Visio origins, stencil-based shapes or many pages.
- Reusable file: the exported VSDX becomes an archive copy that you can re-import and verify without returning to Lucid.
- Known differences: draw.io warns that Visio imports may look different from the original, may lose interactive behavior and do not import embedded EMF images. Review those items first.
- Format choice: draw.io's documented import list names .vsdx, so start with VSDX and confirm any other export format on a test file before using it.
- Storage: after import, the diagram is saved where you choose, such as a local device or a connected storage service.
Open each imported file beside its Lucidchart original, and list every page and embedded image that needs rebuilding before you retire the source document.
Either route can run in an editor you host yourself. The official jgraph/drawio Docker image lets you open draw.io inside your own network, so the paste or import happens on your server instead of the public online editor. The steps are the same, but the conversion stays under your control. The image does not include an export server, so PDF export uses the browser print dialog unless you configure one.
- Where the work happens: when you use your own instance, clipboard content and imported files stay within your network.
- Source of the image: the image is built on Tomcat and kept in step with the hosted app. Pin a specific version tag and record it in your change log.
- Export behavior: PDF output uses the browser print dialog by default, and no diagram data leaves the server for an export.
- Ownership: you own updates, TLS, access control and backups for the instance, and these duties are the main recurring cost.
- Desktop option: draw.io Desktop can handle the same imports for offline work on individual machines.
Ask who will patch the instance and how changes are reviewed, because that owner decides whether the self-hosted route stays current.
Whichever route you choose, the converted diagram can differ from the original. The differences matter most for diagrams that depend on exact placement, interactive links or embedded images. Plan a check for each diagram rather than relying on a single visual pass, and treat the list below as the starting point for that check.
- Layout and routing: shapes and connectors may shift, so verify any diagram where alignment or flow carries meaning.
- Fonts and text: text can wrap or size differently. Confirm the fonts available on the machines where people will open the file.
- Interactivity: links, hover behavior and other interactive elements may not carry over.
- Embedded images: draw.io does not import embedded EMF images, so plan to re-add them as PNG or SVG exports from the source.
- Verification: keep a PDF of each original so reviewers can compare pages directly.
Sign off each diagram against its original and record any accepted differences in the migration log so the decisions can be audited later.
What data and integrations need to move
A Lucidchart move is less about one file type than about several layers: the diagram source, the rendered outputs, the metadata around them, and the places people open them from. Map each layer to a documented export or an integration you rebuild, and decide early which items you will re-create by hand.
Diagram source files
The editable diagram is the asset that matters most. Lucidchart exports each document individually as Visio (VSDX or VDX), which draw.io imports, so this is the route for keeping shapes editable. Export in batches from a folder listing, keep a naming convention, and check a sample of complex diagrams after import because layout and interactive behavior can change. The bulk .LAF backup cannot be used for this move because it restores only into Lucid.
Rendered images and vector outputs
Documents that are only referenced in slide decks, wiki pages or tickets often need a static copy. Lucidchart exports individual documents as PDF, PNG, JPEG or SVG, so you can keep a read-only archive alongside the editable source. Confirm which format each downstream system expects, and note that PDF and image outputs do not carry the editable structure back into draw.io.
Shape data and structured exports
Where diagrams carry linked data, the JSON and CSV exports are the documented way to pull that information out for a register or asset inventory. draw.io does not replicate Lucid's data linking, so decide whether shape data moves as a spreadsheet, stays in a database, or is rebuilt as diagram labels. Ask the team which fields are referenced by other systems before exporting.
Comments, notes and version history
Per-document exports do not carry comments or notes, so review threads and design rationale need a separate capture step. Record open comments in the source document, copy decisions into a changelog or wiki page, and tell reviewers what will not follow the file. Confirm with Lucid's documentation what a given export plan includes before you assume any metadata survives.
Folder structure and sharing
Lucid folders, team ownership and sharing links do not transfer as permissions. Map each folder to a storage location in your chosen system, such as a Nextcloud or SharePoint library, and assign owners before you move content. draw.io saves diagrams where the user chooses, so access control comes from the storage service and not from the editor.
Integrations to rebuild
Diagrams embedded in Confluence, Google Drive, OneDrive, SharePoint, GitLab, Nextcloud or self-hosted wikis need their links and embeds rebuilt. draw.io lists integrations with these storage services and with XWiki, BookStack, Wiki.js and MediaWiki. Inventory every place a diagram is referenced, test each integration with a sample file, and confirm the edit and save path works for each group of users.
Migration sequence from inventory to decommission
This sequence moves Lucidchart diagrams to draw.io in controlled stages, so every diagram has an owner, a verified copy and a recorded sign-off before Lucidchart access is removed. Each stage produces a written artifact that the next stage depends on.
Inventory diagrams and assign owners
Start by listing every Lucidchart document the organization relies on, including folders, shared links and diagrams embedded in Confluence or other wikis. Record the title, the owner, the teams that edit or view each diagram, and whether it is used in a process, audit file or customer deliverable. Ask each owner to confirm the list for their area. This step is done when the inventory is a single list with a named owner for every diagram, and owners have confirmed their items in writing.
Select a representative pilot set
Choose a pilot set that covers the diagram types in use, such as flowcharts, network diagrams, org charts and diagrams with shape data or linked data. Include at least one diagram with complex containers, custom shapes and embedded images, since these are where rendering differences are most likely to appear. Document the selection criteria so the pilot can be repeated if the set changes. The output is a pilot list with the reason each diagram was included.
Run the pilot and log rendering results
For each pilot diagram, export the Lucidchart document to Visio (VSDX) and copy the diagram into the draw.io online editor or a self-hosted draw.io instance, then compare the results. Note shapes that move, lose styling, change text wrapping, or drop interactive behavior, and record any embedded EMF images that do not import. Visio imports may look different from the original, so the reviewer should treat the comparison as a checklist, not a pixel match. The output is a rendering review log with a pass, fix or rebuild decision for each diagram, signed off by the owner.
Migrate in parallel with Lucidchart open
Migrate the remaining diagrams while Lucidchart stays available for reference, editing of unmigrated items and comparison. Each owner converts their diagrams, fixes the issues logged in the pilot, and stores the draw.io files in the storage location the organization has chosen, such as a Nextcloud folder or a Git repository. Keep the rendering review log updated for every diagram. The step is complete when each diagram has a draw.io version, a storage location and an owner confirmation.
Cut over each team to draw.io
Move teams one at a time to draw.io as the working tool. Before a team switches, confirm that its diagrams are migrated, that editors can open and save files in the self-hosted instance or chosen storage, and that links from wikis and documents point to the new files. Announce the change to the team and name a contact for questions. The output is a cutover record for each team listing the date, the diagrams moved and the approver.
Verify exports before decommissioning
Before Lucidchart access is removed, confirm that every diagram the organization must keep has a verified copy outside Lucid. Check the exported files against the inventory, and note what exports leave out, such as comments, version history and some data links, so the team can decide whether that information needs separate archiving. Lucid's bulk .LAF backup restores only within Lucid, so it is not a substitute for these exports. The output is a verification checklist covering every inventory item.
Decommission Lucidchart with sign-off
Once the verification checklist is complete, the accountable owner signs a decommission record approving the removal of Lucidchart licenses and access. Confirm with Lucid how your subscription ends, how long your data remains available after cancellation, and how to obtain any remaining exports. Retain the inventory, rendering review log, cutover records and verification checklist with the decommission record for audit reference. The step is complete when the signed record is filed and access is removed.
What changes in rendering and how to review it
Visio-based imports can look different from the original, and the draw.io documentation says so directly. The import differences page lists three things to plan for: layout and styling may shift, interactive behavior may be lost, and embedded EMF images are not brought over. Lucidchart's own VSDX export is the file that feeds this route, so the same limits apply to diagrams that were built in Lucidchart and then exported. Treat the converted file as a draft that needs a human review, not as a finished copy. Do not promise pixel-level fidelity to a client or stakeholder, because the documentation does not support that promise.
Start the review with a short list of diagrams that matter most, such as architecture diagrams used in audits, network maps and process flows that people follow in production. Open each one in the original Lucidchart document and in the imported draw.io file, then compare them side by side on the same screen size. Check connectors first, since their routing and label anchoring are the parts most likely to change. Next, check fonts: if a font used in Lucidchart is not installed on the reviewer's machine or the self-hosted server, text will reflow and may overflow shapes. Record each difference in a simple log with the file name, the page, and whether the change is cosmetic or functional.
Interactive elements need a separate pass. Hyperlinks, shape data that drives links or lookups, and any behavior that depended on Lucid features must be rebuilt by hand in draw.io, and the reviewer should click through every link and confirm the destination. Decide in advance who signs off each critical diagram and what counts as acceptable, for example whether a re-routed connector is an acceptable change or a blocker. Confirm the current behavior of each import path against the draw.io documentation and your own test files before the migration starts, because the import rules may change between releases.
What drives cost and duration in this migration
This table lists the main drivers of effort and cost when moving Lucidchart diagrams to draw.io, with the reason each one matters and how to keep it down. Read it as a checklist for scoping: the largest costs usually come from internal review time and integration rebuilding rather than from the software itself, which carries no license fee.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Diagram count and complexity | Each diagram needs a copy, paste or Visio import and a visual check. Dense diagrams with many layers, containers and custom shapes take longer to review than simple flowcharts. | Inventory diagrams first, then retire unused or duplicate ones. Migrate simple diagrams in bulk and reserve detailed review for complex, customer-facing or compliance diagrams. |
| Shape data and linked data | Lucidchart shape data and data links do not carry over through the copy and paste route, so any diagram that relies on them needs manual rebuilding or a separate data source. | Export shape data to CSV before migration, decide which links still matter, and document the ones that will be replaced with static labels or a maintained source file. |
| Comments, notes and interactive behavior | Comments, notes and interactive links are outside the diagram itself and may not transfer. Teams must recreate or record them elsewhere. | Export discussions and notes separately, agree where they will live going forward, and confirm with the migration plan which items must be kept as evidence. |
| Integrations to rebuild | Diagrams embedded in Confluence, Jira or wikis need the right draw.io app or connector. Each integration adds configuration, access control and testing. | List every place Lucidchart is embedded. Confirm which integrations draw.io supports for your platform, and prioritize the ones with the most diagrams. |
| Hosting choice | A Docker image on your own server adds server operation, TLS, backups and upgrades. Desktop use removes server work but shifts file distribution and version control to users. | Pick one supported pattern for each group of users. Ask the implementation partner to confirm the image version and upgrade approach in writing. |
| Storage integration | Where diagrams are saved (local device, Nextcloud, SharePoint, GitLab or another connected store) determines access control, backup scope and sharing effort. | Choose the storage that already has backup and access controls. Connect it once, test restore, and document the folder structure before users start saving files. |
| Review and visual checks | Visio and Lucidchart imports can differ in rendering, and draw.io notes that imports may lose interactive behavior. Someone must compare key diagrams with the originals. | Set a sample-based review for high-value diagrams, record acceptance criteria, and reuse the same checklist across teams. |
| Training and adoption | Staff used to Lucidchart need time to learn draw.io's interface, shape libraries and storage model. Lost time often shows up as duplicate diagrams. | Run short role-based sessions, publish a one-page guide with the approved storage locations, and name a local owner for questions. |
| Cost components and recurrence | Internal staff time for inventory, review and training is usually the largest one-time cost. Hosting, storage and maintenance recur. draw.io itself carries no license fee under Apache 2.0, and the source code is free to use. | Ask any quote to split one-time items (inventory, migration, review, training, initial hardening) from recurring items (hosting, backups, upgrades, support retainers). Confirm whether third-party apps or add-ons carry their own terms. |
What usually goes wrong and how to prevent it
Most Lucidchart to draw.io migrations fail on people and process rather than on the diagram file itself. The five risks below cover what gets lost, what changes visually, what breaks in linked documentation, where files end up, and when users are ready. Each one has a check you can run before cutover.
Comments and notes left behind
Per-document exports and the draw.io paste route carry shapes, text and layout, but review comments and speaker notes are not part of the diagram data you move. Reviewers may have approved a diagram in Lucidchart on the basis of feedback that exists only in the old tool. Before cutover, ask each diagram owner to record open comments in a register or resolve them, and keep the Lucidchart account readable for a defined period so the history can be checked. Confirm with a test document exactly which elements survive your chosen route.
Rendering changes in regulated diagrams
A diagram that looked right in Lucidchart can render differently after import, which matters when a network topology, data flow or control map is reviewed as evidence. The draw.io Visio import documentation warns that imports may look different, may lose interactive behavior and do not import embedded EMF images. Pick a sample of diagrams from each regulated domain, export them before and after, and compare them side by side with the diagram owner. Record sign-off for each one.
Broken links to Confluence and wiki pages
Diagrams embedded in Confluence pages, wiki articles or Jira tickets are often referenced by URL, and those references point at Lucidchart documents that will be retired. Moving the file does not update the page that links to it. Inventory where each diagram is embedded before migration, decide whether the target page will hold a draw.io diagram or a file link, and update the references in the same change window. Test a sample of links after cutover rather than assuming they resolve.
Diagrams saved in personal folders
draw.io saves diagrams where the user chooses, on a device or in a connected storage service, so nothing is centralized by default. Without a shared location, diagrams end up on laptops, in personal Drive folders or in downloads, and nobody else can find them when someone leaves. Set one approved storage location per team, such as a Nextcloud or SharePoint folder, configure the draw.io integration for it, and make the folder the only place migrated diagrams are saved.
Cutover before users are trained
Users who have not practiced the new editor will rebuild diagrams from memory, paste into the wrong place or keep working in Lucidchart out of habit, which creates two versions of the same diagram. Run short hands-on sessions covering import, saving to the approved location, sharing and exporting before the switch, and name a contact for questions during the first weeks. Make the cutover date conditional on a training completion check for each team, not on the calendar alone.
How the migration differs by team size and starting point
A small team with a modest diagram library can usually treat the move as a document-by-document exercise. The work is mostly selecting the diagrams that still matter, moving them through the browser or a Visio export, and checking that each one still reads correctly. Desktop draw.io or the online editor pointed at storage the team already controls is often enough, and the main decisions are about naming and folder structure rather than infrastructure.
- Inventory first: List the diagrams that are still referenced in documents, onboarding material or incident runbooks, and archive the rest.
- Choose one route per diagram: Use copy and paste for simple flowcharts and the VSDX export for diagrams that carry Visio-style shapes or stencils.
- Keep storage simple: Save files to a shared drive or an existing file server that the team already backs up.
- Assign one owner: A single person can review each migrated diagram against the original, which keeps the effort contained.
- Decide on desktop or web: Desktop draw.io avoids running a server, while the self-hosted Docker image suits a team that wants a shared URL.
Before cutover, confirm with the team which diagrams have comments or review history in Lucidchart, because those do not move with the shapes and must be captured separately.
A large organization with hundreds of diagrams, shared folders and diagrams embedded in Confluence pages has a different problem. The migration becomes a portfolio decision: which diagrams are owned by whom, which pages link to them, and how embedded diagrams are re-pointed without breaking documentation. Governance, naming and a clear cutover date matter more than the conversion itself.
- Map embeds and links: Find every Confluence page or wiki article that embeds a Lucidchart diagram, since each one needs a replacement or a re-embed.
- Run pilot batches: Convert one business area first, record the differences found, and refine the checklist before the next batch.
- Set ownership by space: Each Confluence space or team folder needs a named owner who signs off on the migrated versions.
- Plan the integration: Decide whether draw.io will run as an app inside Confluence or whether diagrams will be stored in a connected file system or wiki.
- Agree a freeze date: Stop new Lucidchart edits on migrated content so that the two copies do not drift.
Check with your Confluence administrator how draw.io apps are licensed and deployed in your environment, since the Atlassian Marketplace listing is the route the draw.io documentation describes for Confluence and Jira.
A regulated organization, such as a bank, healthcare provider or public body, usually needs more than a working diagram. It needs to show where diagram data is stored, who can reach it and how the storage is governed. Self-hosted draw.io changes the question from a vendor's residency commitment to the organization's own storage design, which makes evidence collection part of the project scope from the start.
- Document the storage location: Record the storage service, region and access controls for every location where migrated diagrams are kept.
- Review the processing path: draw.io's privacy statement says hosted export and real-time collaboration process diagrams temporarily on servers run by Cloudflare, so confirm whether those features are enabled and whether they are allowed under your data rules.
- Control the export files: Treat VSDX and JSON exports as sensitive copies and set retention rules for them.
- Run an approval step: Involve data protection, security and records management before the first production diagrams move.
- Keep change records: Keep a log of the migrated set, the approver and any diagrams excluded from the move.
Ask your data protection officer and assessors which evidence they expect, and confirm the behavior of the self-hosted image and any optional export service against your own control set before cutover.
Questions buyers ask before moving from Lucidchart to draw.io
How much effort and time does a move from Lucidchart to draw.io take?
The effort depends mostly on how many diagrams you have, how many of them are complex, and whether they need to be converted in bulk or only when someone next opens them. No timeline figure has been published for this migration, so ask for one in writing. The main drivers are the diagram count, the number of Visio stencils or custom shape libraries in use, how many diagrams embed images or interactive links that must be rechecked, and whether you also need to move storage and access rules. Ask the implementer to break the estimate into inventory, conversion, review and handover so you can see where the time goes.
Can an internal team migrate Lucidchart diagrams to draw.io on its own?
Yes, for a small set of diagrams, a single team can copy and paste or export and import them without outside help. The routes are copy and paste from Lucidchart into the draw.io online editor, or export to VSDX and import into draw.io. Larger estates usually need a repeatable process, a review step for layout changes, a decision on where files are stored, and someone to set up the self-hosted instance. Teams without spare platform or documentation capacity often bring in an implementation partner for those parts, and DeployOpen works that way on a fixed scope.
What does the work need from our team?
Expect to supply a named owner for the diagram inventory, reviewers who know the diagrams well enough to spot wrong labels or broken connectors, and someone who can approve where the self-hosted draw.io instance and its storage will run. Your platform team will also need to provide the hosting environment, whether that is a container host or a desktop install for users, and any single sign-on or storage integration you require. Confirm each of these responsibilities in the written scope so nobody assumes another group owns them.
Do diagrams stay on our servers after moving to draw.io?
Diagrams stay where you choose to save them. draw.io's trust page says diagrams are saved on the device or in a connected storage service, never on draw.io's servers. The self-hosted jgraph/drawio Docker image runs in your infrastructure, so the instance itself does not send diagram data out during normal editing. Features such as hosted export and real-time collaboration process diagrams temporarily on servers run by Cloudflare, so confirm whether you need those features and how the export options are configured in your deployment.
Can draw.io import Lucidchart diagrams, and what is lost?
draw.io imports Lucidchart diagrams, and the documented method is to copy everything in Lucidchart with the keyboard shortcut and paste it into the draw.io online editor. Export to Visio is a second route, because draw.io imports .vsdx files. Visio imports can look different from the original, can lose interactive behavior, and do not bring in embedded EMF images. Comments, notes and version history from Lucidchart do not move with the diagram. Test a representative sample of each diagram type before committing to the full conversion.
Why can't we use Lucid's bulk .LAF backup to move everything?
The .LAF file is a bulk export format that Lucid uses to restore documents within Lucid, so it cannot be opened by draw.io. Individual documents can be exported as PDF, PNG, JPEG, SVG, Visio (VSDX or VDX), JSON or CSV, and those per-document formats are the starting point for the move. Plan the inventory around these exports, and ask your implementer how they will handle any diagram that has no clean export path.
What should we ask for in a written scope?
Ask for a list of the in-scope diagram sources, the conversion routes that will be used, and a sample conversion review with agreed acceptance criteria. The scope should name the self-hosted deployment target, the storage location, any Confluence, Nextcloud or wiki integrations, and who handles backup, upgrades and user guidance after handover. Ask how Visio and Lucidchart losses will be documented and who signs off on them. Most engagements are fixed-scope, so the written scope sets the deliverables and timeline before work begins.
Will the migration support compliance evidence for data handling?
DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Ask the implementer to document where diagrams are stored, who can access them, how the instance is configured and how changes are logged, so your auditor has the evidence they need.
How DeployOpen scopes and runs a draw.io migration
DeployOpen starts by inventorying the Lucidchart diagrams, stencils and storage locations in scope, then agrees the migration route and target storage in writing. Engagements are fixed-scope, with deliverables and timelines confirmed before work begins.
How we scope
- Inventory which Lucidchart documents, shape libraries and linked data must move, and which can be retired.
- Choose between copy and paste into draw.io and the VSDX export route for each diagram group.
- Agree in writing where diagrams will be stored, such as a self-hosted Nextcloud or another storage service you select.
How we build
- Deploy the official jgraph/drawio Docker image inside your own cloud account, data center or air-gapped network.
- Configure storage integrations and export handling so diagrams and exports stay where you choose.
- Test converted diagrams against the originals and document each rendering or interactivity difference found.
How we hand over
- Deliver a migration log listing each diagram, its route, its status and any items needing manual rework.
- Document the deployment, upgrade steps and backup routine so your own administrators can operate draw.io.
- Provide a record of the controls and configuration evidence your internal or external assessors may request.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Confirm with your team which upgrade cadence and change approval process applies to the draw.io instance.
- Request a quote based on the written scope, which sets out the components, effort and recurring work.
