Can Visio files be opened in Collabora Online without a desktop application?
Yes, Visio files can be opened in Collabora Online without a desktop application, because the Collabora Online product page lists Visio among the formats it supports. Other legacy formats, including Publisher, WordPerfect and Hangul, are not covered by that listing, so you should confirm each one against the exact Collabora Online version you plan to deploy before you rely on it. For an archive of older diagrams, publications and word processor files, treat support as a per-format question, not a blanket yes.
Teams usually need this capability for two reasons. The first is retiring desktop licences: when staff no longer have Visio or Publisher installed, files must still open and be edited in the browser. The second is moving document storage into Nextcloud or another WOPI host, where people open files from the storage layer rather than from a local application. In both cases, the opened file is only half the question, because the saved-back file must also remain usable for colleagues who still work in desktop tools.
DeployOpen plans the test and conversion work for these files, including building a sample set from your archive, opening and re-saving each format, comparing results against the originals and deciding which files need conversion to a modern format. DeployOpen does not guarantee fidelity: how a particular diagram or layout renders depends on the source file and the deployed release, and the results are a record of what was tested in your environment, not a promise about every file.
Which legacy format decisions shape the project
This table compares the main decisions for each older or niche format family, from Visio to legacy Office binaries. Read each row as a question to answer before rollout: what the documentation says, what to test in your build, whether to edit in place or convert first, and where the format usually fits. Where the supplied documentation is silent, the cell says so and names what to confirm.
| Format family | Status in the documentation | What to confirm in your build | Edit in place or convert first |
|---|---|---|---|
| Visio (.vsdx and .vsd) | Listed among supported formats on the Collabora Online product page | Open your own diagrams, check shapes, connectors, stencils and text placement after save | Edit in place for simple diagrams; convert complex diagrams after review |
| Publisher (.pub) | Not listed in the supplied product documentation; confirm import support directly | Whether the file opens at all, and whether layout survives import and save | Convert to PDF or a document format for editing; keep the original |
| WordPerfect (.wpd) | Not listed in the supplied product documentation; confirm import support directly | Opening, pagination, fonts and tables in a representative sample | Convert to ODT or DOCX before wide editing, then test the result |
| Hangul (.hwp) | Not listed in the supplied product documentation; confirm import support directly | Opening, character encoding, Korean fonts and table layout on your servers | Convert to a supported format first if the source team can work with it |
| Legacy Office binaries (.doc, .xls, .ppt) | Covered by the general Microsoft format support described on the product page; confirm the exact set in your release | Round-trip fidelity for macros, embedded objects, charts and fields | Edit in place for routine files; convert to OOXML for long-term archives |
| Bulk archives | Not described in the supplied documentation for bulk conversion | Batch conversion tooling, error logging and file counts you need to process | Convert in a separate pipeline with logs, keeping originals read-only |
How each format family behaves when opened in the browser
Collabora Online's product page lists Visio files among the formats it supports, next to OpenDocument, Microsoft Word, Excel and PowerPoint formats, PDF, RTF and CSV. That listing confirms import at the product level. It does not describe how individual diagrams render, which shape features survive, or how edits are written back to storage. Treat Visio as a supported import with fidelity risk, and confirm the behavior on diagrams taken from your own estate.
- Shapes and stencils: Custom masters, stencils and shape data may render differently or lose behavior once the drawing is edited in the browser.
- Connectors: Connector routing and glued connections are a common source of visible change after a round trip, so check that flowcharts still link correctly.
- Fonts: Text that uses fonts missing from the Collabora server is substituted, which changes label width and can move text out of its shape. Ask your administrator which fonts are installed.
- Embedded objects: Embedded images, OLE objects and linked data may be dropped, flattened or left unreadable. Test each object type your diagrams actually contain.
- Save-back: Confirm whether the file is saved in Visio format or converted, and keep the original copy in storage until the round trip is signed off.
Compare each diagram type against the original in Visio and keep the source files until the comparison is complete.
The Collabora Online documentation available for this topic does not list Microsoft Publisher among the supported formats. That silence does not tell you whether a Publisher file will open, and it does not tell you how it will be saved. Publisher is a page layout format, so the risks sit in the parts of the layout that a browser editor may not represent faithfully. Plan to test import and save-back on representative files before anyone relies on them.
- Page layout: Frames, text threads between frames, master pages and column grids are the features most likely to shift when the file is reflowed or rendered.
- Images and color: Check how placed images, cropping, transparency and color profiles appear after opening and after saving.
- Fonts: Publisher designs often depend on specific or licensed fonts. Missing fonts on the server change line breaks and page count.
- Read-only or rejection: Some files may open in read-only mode or be refused. Record which happens, because read-only access blocks editing and rejection blocks access entirely.
- Conversion targets: If a Publisher file is converted to another format on save, decide whether that output is acceptable for the document's purpose.
For any Publisher file that will stay in production, keep the original and make the go or no-go decision from your own test results.
The Collabora Online documentation available for this topic does not list WordPerfect files. Legacy WordPerfect documents are text-centric, so the main concerns are usually styles, tables, headers and footers, and character encodings, rather than complex graphics. Whether Collabora opens a given WordPerfect version, and how it saves the result, must be verified with files from your archive. Do not assume that a file which opens will save back without loss.
- Styles and formatting: Legacy paragraph and character formatting may map to different styles, which changes the look of long documents.
- Tables and columns: Complex table structures, merged cells and multi-column sections are common points of drift.
- Headers, footers and fields: Page numbering, cross-references and footers can be lost or recalculated differently.
- Encoding: Older files may carry legacy character encodings that display incorrectly if the file is misread.
- Failure logging: When a file opens read-only or is rejected, record the file name, WordPerfect version if known, file size, the exact error or warning text, the Collabora Online version, the browser and the WOPI host.
Use your logs to decide which WordPerfect versions can be edited in place, which need conversion first, and which should remain archived.
The Collabora Online documentation available for this topic does not list Hangul (HWP) files. Hangul documents are common in Korean public and private sector archives, and their handling depends on font availability, encoding and how the layout was built. Because no supplied documentation covers them, the only reliable answer for your archive comes from testing. Involve a reviewer who reads Korean, since visual errors in Hangul text are easy to miss for other readers.
- Fonts and glyphs: Korean text requires suitable fonts on the server. Without them, characters may render as boxes or substitute to fonts with different metrics.
- Layout and spacing: Line breaks, mixed-script spacing and table layouts can shift after opening and saving.
- Read-only or rejection: Some Hangul files may open read-only or be refused. Record each case with the file name, file size, error text, Collabora Online version, browser and WOPI host.
- Save-back format: Confirm what format the file is saved in and whether it can be opened again in the Hangul application used by your staff.
- Corpus coverage: Include files from different eras and producing applications, because a single sample rarely represents the whole archive.
Before any Hangul archive is moved into the browser editor, agree with the business owner which failures block go-live and which can be accepted.
How to set up and test legacy file handling step by step
This sequence turns an unknown archive of older and niche files into a tested decision about what Collabora Online can open, edit and save back, and what must be converted or kept in its original form. Each step closes with a written check so the go or no-go decision rests on evidence from your own files.
Inventory formats and file counts
Scan the archive or export listing and count files by extension and by detected type, including Visio, Publisher, WordPerfect, Hangul and any older Office or OpenDocument variants. Record the number of files, total size and owning team for each format, and note files with no extension or mixed content such as embedded objects. The step is complete when the team that owns the archive signs off on the inventory, so every format that could reach the editor is named before testing starts.
Build a representative sample set per format
Select sample files for each format that reflect real use: the oldest and newest versions, the largest and smallest files, files with embedded images, fonts, macros or linked objects, and files produced by the most common authoring tools. Keep a copy of every original in read-only storage and record its source, version and checksum so later results can be traced. The step is complete when a business owner reviews the sample list and confirms it covers the content that matters to them.
Confirm the Collabora Online version and import filters
Record the exact Collabora Online version and deployment type you will test, then check its supported format list against the Collabora Online product page and the release notes for that branch. Confirm with Collabora or in your own environment which import and export filters the build includes for each sample format, because support for niche formats can differ between releases. The step is complete when the version, the source of the format claims and any formats marked as unconfirmed are written into the test plan.
Configure the WOPI host for test tenant access
Point a non-production WOPI host, such as a test Nextcloud instance, at the test Collabora Online server, and restrict WOPI requests to the expected server addresses using the same protocol for both URLs. Upload the sample set to a test library, create a test group with editing rights, and confirm that the sample files open from the host with the expected permissions. The step is complete when every sample format opens in the browser from the test tenant and the configuration is recorded in a change log.
Run open, edit and save-back round trips
For each sample, open the file in the editor, make a defined set of edits such as changing text, a table cell, a shape or a page element, then save and close. Reopen the saved file, compare it with the original and with a copy saved in the source application, and check the saved format, page or slide count, fonts, images and any objects that were dropped or altered. The step is complete when every sample has a recorded result for open, edit and save-back, with screenshots or exported comparisons kept as evidence.
Log defects with severity
Record each difference as a defect in a shared tracker, with the sample ID, format, step where it appeared, observed and expected results, and a severity such as blocking, workaround available or cosmetic. Agree the severity scale with the business owners before triage so that a lost signature block and a shifted font are not treated the same way. The step is complete when every defect has an owner and severity, and the list has been reviewed in a triage meeting with sign-off from the business and the platform team.
Decide the conversion path for production
For each format, choose one of three paths: open and save back in place, convert to a modern format before loading into the editor, or keep the original read-only and provide an export for viewing. Base the choice on the blocking defects, the number of files affected, and whether the archive must remain in its original form for legal or records reasons. The step is complete when a signed decision record lists the path for each format, the remaining known issues, and who approved the go-live scope.
How saving back changes the file you keep
Saving a legacy file back is a decision about which copy your organization keeps. A user can overwrite the Visio, Publisher or other legacy file in its original format, or save a new file in a modern format such as OpenDocument or OOXML and leave the source untouched. The save-as format a user picks, together with the default format set by the WOPI host, determines what the user actually receives. In a Nextcloud deployment, confirm with your administrator which default format applies to new and re-saved files, and test both paths before you tell users which one to use.
Re-saving a legacy file can change its layout, styles and embedded objects, because the source format is rebuilt from the editor's internal model on export. Shapes, connectors, master pages, fonts and embedded content are the items most likely to shift, and the effect is often invisible until someone opens the file in its original application. Treat the original as the system of record until your fidelity review is signed off, and keep it in a read-only location or versioned storage so a bad save can be reversed.
Build this into the review plan rather than leaving it to individual users. Ask the reviewers to compare the original and each converted copy side by side, log every difference, and record which format the business will accept as the long-term copy. Only after that sign-off should you change overwrite behavior or allow bulk conversion of the archive. Ask your Collabora Online integration partner or host vendor to confirm how their save-back and default-format settings behave for each legacy format you rely on.
Where legacy fidelity most often breaks
Legacy and niche files fail in predictable places: drawing geometry, fonts, page layout, character encodings, embedded objects and macros. Each card names the symptom a tester sees and the check that should catch it before any file is opened by real users.
Visio shapes and connector routing
Visio diagrams often rely on custom stencils, grouped shapes and connectors that reroute when a linked shape moves. A file can open with boxes in the right place while connector paths bend differently or labels drift off their shapes. Test with diagrams that use your own stencils, then compare connector endpoints and text placement against the original in Visio. Confirm current Visio coverage with Collabora before you commit to a diagram workflow.
Fonts missing on the server
Publisher and older Office files frequently embed or reference fonts that the Collabora server does not have installed. The symptom is line breaks that move, text that reflows across pages and tables that change width, even though the content looks correct. Build a font inventory from a sample of legacy files, install the licensed fonts on every Collabora node, and compare page counts before and after the server change.
Publisher page layout and frames
Publisher stores layout as independent frames, master pages and text threads, which do not map cleanly onto a word processor's flow model. Testers will see text boxes that overlap, images that shift relative to their frames and master page elements that disappear. Check a representative set of brochures and newsletters page by page, and decide in advance which files stay in their original format and which are rebuilt.
WordPerfect and Hangul character encodings
Older WordPerfect and Hangul documents can use code pages, legacy encodings and specialized character sets that display incorrectly when the encoding is misread. The symptom is mojibake, missing glyphs or Hangul syllables replaced by question marks in headers, footers and tables. Test with documents in each language your organization uses, check both on-screen display and the text after export, and verify that the fonts for those scripts exist on the server.
Embedded objects and OLE content
Older files often contain embedded OLE objects such as spreadsheets, equations, charts and other documents. These may open as static pictures, lose their links to the source data or refuse to activate in the browser. A tester should double-click each embedded object in a sample file, confirm that the data still updates or remains readable, and record which object types become images only so that business owners accept the change.
Macros and scripts in older files
Legacy files can carry VBA macros, form scripts or field logic that drives calculations and mail merges. Collabora does not run the same macro code as desktop Office, so the symptom is a document that opens and displays but stops calculating or automating. Inventory which files contain macros, record what each one must do, and decide per file whether the macro is rewritten, retired or kept in the desktop workflow.
Converting archives in bulk without losing the originals
The first decision is whether to convert a legacy archive once, in a batch, or to keep conversion on demand when a user opens a file. A one-time batch gives you a fixed set of modern copies to review and index, but it locks in the importer version and font set that existed on the day you ran it. On-demand conversion always uses the current importer, yet every open carries a conversion cost and the results can shift between sessions as the software changes. Most teams with large Visio or Publisher holdings choose a batch for the bulk of the archive and on-demand handling for the long tail of files that people still need. Whichever you choose, write the decision down before the first file is touched, because it determines what you can later say about any given document.
Keep the originals untouched. Mount the source archive as read-only storage, so no conversion step, script or user session can overwrite a legacy file. Write converted copies to a separate location with its own naming and folder structure, and record a checksum for each source and output so you can prove which original produced which copy. Log every conversion failure by file path, source checksum, importer version, font set and error text. A failure log is the working list for remediation, and it is also the evidence an auditor or records owner will ask for when a document cannot be opened in its modern form. Confirm with your records or legal team whether converted copies replace the originals in any retention or records schedule, since that answer is not a technical default.
Plan to rerun failed files. When the importer, a font package or the Collabora Online version changes, rerun only the failed entries from the log, then compare the new results with the earlier output rather than overwriting it. A headless conversion pipeline must be validated against the same representative sample set you used for interactive testing, so that batch output and browser output agree on the files that matter. Treat the pipeline itself as software that needs versioning and sign-off. DeployOpen scopes the conversion tooling, validation method and rerun procedure in the written statement of work, so the sample set, acceptance criteria and handover of scripts are agreed before the batch starts.
Security considerations for old files from unknown sources
Visio, Publisher, WordPerfect and Hangul files are often old, sent by outside parties and parsed by converters that have their own history of flaws. The controls below address the file, the server that parses it, the hosts that can reach that server, and the people who can change what is stored.
Treat legacy files as untrusted input
Assume every Visio, Publisher, WordPerfect or Hangul file received from outside the organization may be malformed or hostile, and treat it that way even when it arrives from a known sender. Older binary formats are where parser bugs have historically concentrated, so opening them should not be the first time anyone checks them. Decide which sources are allowed to feed the editor, and route unknown files to a quarantine location first. Record who approved each source so the decision can be reviewed later.
Keep the server patched
Collabora publishes security advisories for Collabora Online, and the 25.04 release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623. Track the advisories for the branch you run, apply point releases on a schedule, and confirm that the package signing keys on your RPM or DEB repositories were updated. Ask Collabora or your DeployOpen contact which branch receives signed security updates for your plan before you commit to one.
Restrict which WOPI hosts connect
Only your WOPI hosts, such as Nextcloud, should be able to reach the Collabora server's WOPI endpoints. The Nextcloud administration manual recommends restricting WOPI requests to the IP addresses of the Collabora servers, so the host allow list and the network rules should match. Review both after every change to load balancers, proxies or host addresses, because a stale rule can either block editing or leave the endpoint open to anyone who can reach it.
Use TLS between host and server
Files travel from the host to the Collabora server over the WOPI connection, and document contents and access tokens travel with them. The Nextcloud manual recommends using the same protocol for the Collabora server URL as for the Nextcloud installation, preferably HTTPS. Confirm that certificates are valid, that the server URL uses the scheme you intend, and that no internal hop downgrades the connection between your load balancer and the Collabora pods.
Scan archives before conversion
Visio, Publisher and some Hangul files can arrive inside ZIP or other archives, and an archive can hide files that are not what their extension claims. Run antivirus and file-type checks on archives and their contents before they reach the editor, and reject or quarantine anything that fails. Bulk conversion jobs should use the same gate, so a batch of archived legacy files cannot skip the scanning step that single uploads receive.
Limit who can edit
Nextcloud Office lets administrators limit which groups can use the editor and which groups can edit rather than only view. For legacy formats, consider letting most staff view converted copies while only a small group edits imported originals. Document the group mapping, review it when staff change roles, and confirm that read-only sessions behave as you expect for Visio and Publisher files before you rely on them.
What to confirm before you promise legacy format support
Before you tell business users that Visio, Publisher, WordPerfect or Hangul files will open and save cleanly, confirm the behavior in your own environment. The supplied Collabora documentation names Visio among the supported formats. It does not give the same level of assurance for Publisher, WordPerfect or Hangul, so treat those as unconfirmed until you have written confirmation from Collabora or results from your own tests. Record the exact Collabora Online version you plan to run, because import filters change between branches, and check the release notes for the branch you select.
Next, check the parts of the environment that change how a file looks even when it opens. Fonts installed on the Collabora Online server determine whether text and diagram labels in a legacy file are substituted, so compare your server font set with the fonts used in your source files. Then check the WOPI host configuration. Nextcloud and other hosts can restrict which file extensions are offered to the editor or whether a file can be saved back, and a format that opens in a standalone test may be blocked or downgraded inside your host. Confirm both the import and the save-back path, since a file that opens read-only is not the same outcome as one that round-trips.
Write down which formats a business process depends on, and ask the vendor to confirm each one in writing, naming the Collabora Online version and the WOPI host. Where a process depends on a format that is not clearly documented, plan a fallback such as keeping the original file in its native application, converting on a controlled workstation, or limiting the workflow to read-only access. Run your representative files through open, edit and save-back cycles, and keep the results with the version and fonts used, so the evidence can be repeated after each upgrade.
Questions buyers ask about legacy file support
What drives the cost of a legacy archive project in Collabora Online?
The cost follows the size and variety of the archive and the fidelity bar you set. The main drivers are the number of sample files you test, how many distinct legacy formats appear (Visio, Publisher, WordPerfect, Hangul and others each behave differently), how strict the sign-off is for layout and content, and whether bulk conversion is in scope. A small set of common files with a loose bar costs far less than a mixed archive where owners must approve every document. Any fixed-scope quote should list the sample size, the formats, the acceptance criteria and the conversion targets in writing. Collabora Online itself is licensed under MPL-2.0 and, in the case of paid support, priced per user per month, so software licensing is usually a separate line from this work.
How long does a legacy file conversion project take?
Duration depends on the archive and the test scope, and no fixed figure applies across environments. The schedule is driven by how many files and formats need testing, how many rounds of review the document owners need, how much conversion output must be checked by hand, and how long the bulk job runs on your hardware. Start by counting files per format and per owner, because that count sets most of the effort. Ask any provider for a timeline tied to a written scope with defined deliverables, and check whether it includes the review cycles your owners will need.
What must our internal team provide before the work starts?
Your team needs to supply four things. First, a file inventory listing where legacy files live, their formats and approximate counts. Second, named owners for each document group who can sign off on fidelity, since only they know whether a rendered layout is acceptable. Third, a test tenant or environment where Collabora Online is deployed with the same version and settings as production, so results carry over. Fourth, access to the original files and a decision on what storage space is available for converted copies. Without these, testing stalls at the sign-off step.
Can our team handle a legacy archive project without outside help?
Yes, for a small set of common files your team can usually test and convert alone, provided someone owns the inventory and sign-off process. Difficulty rises when formats are niche or the archive is large. Visio diagrams with complex shapes, Publisher layouts that depend on fonts and exact placement, and WordPerfect or Hangul files with unusual features need careful checking, and fidelity problems may only show up in specific cases. Consider outside help when you need repeatable test results across many formats, a documented method your auditors can follow, or bulk conversion that must run unattended and be verified afterward.
Is converting legacy files in Collabora Online reversible?
Conversion is reversible only if you keep the original files. When Collabora Online saves a legacy document in another format, the original binary is replaced in the new file, and some features may not survive the round trip. Keep the originals in a separate, read-only location until owners have signed off and you have a retention decision in place. Store the converted copies beside the originals rather than overwriting them, and record a checksum for each source file so you can confirm which version you hold later. Treat any bulk job as a one-way change unless this safeguard is in place.
What should a quote for legacy file support include?
A useful quote lists the scope in writing. It should name the formats in scope, the sample size per format, the fidelity criteria and who signs off, the bulk conversion volume and target formats, and what counts as a deliverable, such as a test report, a list of known issues and a conversion log. It should state what the internal team must provide, the test environment, and how issues found during testing are handled. Ask whether the price is fixed for the written scope and what triggers a change request. Also ask whether ongoing support is needed after delivery, since that is a separate retainer. DeployOpen works from fixed-scope written agreements, so the quote follows the scope rather than a published price list.
Does a conversion output from Collabora Online need compliance review?
Converted archives can matter for records retention, evidence and audit, so the answer depends on your obligations. Collabora Online does not certify documents, and a successful conversion does not establish that a record is complete or authentic. Confirm with your records and compliance owners which formats are legal records, what retention rules apply and whether a conversion log must be kept as evidence. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit reports or attestations.
How DeployOpen scopes and delivers legacy file handling
DeployOpen plans, implements and documents Collabora Online inside your own infrastructure, including how Visio, Publisher and other legacy files are opened, saved and converted. The work starts with a written scope that names the formats, sample files and checks that matter to your organization.
How we scope
- We list the legacy formats your archives and workflows actually contain, including Visio, Publisher, WordPerfect and Hangul where present.
- We agree in writing which files must open, which may be converted, and which stay in their original format.
- Engagements are fixed-scope, with deliverables and timelines agreed before work begins, and a quote follows from that written scope.
How we build
- We assemble a representative sample set from your archives and run it through import, edit and save-back tests in Collabora Online.
- We design and script bulk conversion jobs for archives, with logs that record each source file, output and any failure.
- We record fidelity findings per format, so decisions on keeping originals or converting are based on tested results.
How we hand over
- You receive the written test results, the conversion scripts and the decision record for each legacy format in scope.
- We document the user guidance, known limitations and the steps to re-run tests when Collabora Online is upgraded.
- We walk your administrators through the conversion tooling so your team can run future batches under its own control.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, including retesting legacy formats after new Collabora Online releases.
- A retainer can cover re-running the sample corpus when your archive grows or when new legacy formats must be added.
- Ask us to confirm which format behaviors are current for your Collabora Online version before you commit to a conversion plan.
