Handling VBA macros and Office automation when moving to Collabora

No. Collabora Online opens macro-enabled Microsoft formats but disables macros online, according to the Collabora FAQ. Users can open the file, but the macro code does not execute in the browser editor. That makes the FAQ the first document to read when you start an inventory of macro dependencies. Confirm the behavior for your exact version with Collabora before you write user guidance, because the FAQ describes the product in general terms. In your inventory, check two things: whether anyone expects a button or report inside a shared file to run, and whether a macro calculates or validates data that people rely on. If either is true, that workflow needs a separate path, and browser editing alone will not cover it.

COLEAT is the Collabora OLE Automation Tool. According to the COLEAT page, it wraps legacy Visual Basic line-of-business applications so they can talk to Collabora Office instead of Microsoft Office on Windows, and it traces the automation calls it receives. Use it when a Windows application drives Office through OLE Automation and that application must keep working with Collabora Office. Collabora says API coverage is still being extended, so some calls your application makes may not be supported yet. Treat the trace as a discovery aid: it produces a concrete list of calls to test. Confirm current API coverage with Collabora against that list before you commit to this path.

No. COLEAT works with Collabora Office on Windows, the desktop product, and targets applications that automate Office through OLE. It does not add VBA execution to Collabora Online, so a browser user who opens a macro-enabled file still gets the macro-disabled behavior described in the Collabora FAQ. Browser editing and desktop automation are separate decisions. A line-of-business application that depends on OLE Automation usually needs a Windows desktop path, while the browser path serves people who only read or edit documents. Ask Collabora whether the tool covers the methods your application calls, which Collabora Office versions it supports, and how it behaves when a call is not yet implemented.

The Collabora Online product page lists OpenDocument formats and Microsoft formats including docx, xlsx and pptx, plus PDF, RTF, CSV and Visio files. A format list tells you what opens, not whether every feature in those files behaves the same. Macro-enabled variants follow the FAQ behavior: they open with macros disabled. Map every file type in your inventory to the list, then test representative files that use templates, form controls, tracked changes, pivot tables and macros. Compare the results with the desktop original. A workbook can open correctly and still calculate differently, so verify values, not only appearance.

Check the Collabora Online release notes for the branch you plan to run and for its newest point release. The 25.04 release notes, for example, record that the 25.04 branch was first released on June 19, 2025, and that point releases continued into 2026, with 25.04.13 released on September 21, 2026. Your test results apply only to one build, so record the exact version string in the test plan and repeat key macro and automation checks after each point release. The same notes record security fixes, such as CVE-2026-23623 fixed in 25.04.7.5. Confirm with Collabora which build your support arrangement covers before you certify a workflow.

Most teams can do the inventory themselves, because the work is mostly reading, listing and testing. Start with every macro-enabled file, every Visual Basic application and every automation call those applications make. The cost is mainly staff time, a Windows test environment and representative data. Owners, usage frequency and the sensitivity of the data matter more than the raw file count, so rank the list before you test everything. An outside partner adds value when the list is long, the code is poorly documented or the testing needs Windows desktops and realistic data sets. Ask any partner for a written, fixed-scope proposal that names the deliverables, the systems in scope and what you must provide, such as access, sample files and named business owners.

Cover three areas, each with its own pass criteria:

• Every macro-enabled file opens in the browser, shows the expected content, and is documented with the macro behavior users will see.
• Every automation call in the trace is either supported by COLEAT for the target Collabora Office version or has a documented replacement.
• Output from each workflow, including calculated values, exported PDFs and generated letters, matches the desktop baseline.

Record the Collabora Online build, the Collabora Office build and the Windows version for each run. Re-run the suite after each point release and after any change to the workflow.

No. Collabora Online opens macro-enabled Microsoft formats, but it disables macros in the browser, so a macro-enabled workbook or document can be viewed and edited there without its automation running. Any process that depends on a macro needs a decision before cutover: rewrite the logic, move it to a server-side or desktop route, or retire it. Confirm the exact behavior for each file type you hold, because a document can open and look correct while the macro it contains is inert. Collabora's FAQ at Collabora Online FAQs is the place to check the current position.

Not necessarily. COLEAT, the Collabora OLE Automation Tool, lets legacy Visual Basic line-of-business applications talk to Collabora Office instead of Microsoft Office on Windows, and it traces the automation calls it receives. Collabora says its API coverage is still being extended, so the practical test is to run your application's real call sequence against it and list every call that is unsupported or behaves differently. Ask the vendor for the current coverage list and compare it with the trace from your own test runs. See COLEAT for the tool's stated scope.

Effort depends on how many applications call Office, how many macros exist, how well documented the code is, and whether the original authors are still available. The main drivers are the count of distinct automation entry points, the number of shared templates that many files depend on, and the amount of undocumented business logic. A useful inventory records each macro, its trigger, the data it reads and writes, its owner and its users. Ask any partner for a written inventory method and a deliverable format before agreeing to a fixed fee, since an inventory that stops at file counts will miss the calls that matter.

Yes, many teams can, provided someone can read the VBA source, run the applications in a test environment and record their Office calls. The team needs access to the code repositories, a Windows test machine with the relevant Office and Collabora Office versions, and time from application owners to confirm what each process is for. Where the team lacks VBA or Windows automation skills, or where the code is poorly understood, a partner may be the faster route. Decide early who signs off each dependency, since an inventory without business owners tends to leave the riskiest processes unclassified.

The work needs a complete list of applications and file shares, read access to VBA source and templates, a Windows environment that matches production as closely as possible, sample documents that reflect real use, and named owners for each business process. It also needs a test plan that covers both the document fidelity checks and the automation calls. Without these inputs, testing shows only that the software starts, not that the process still works. Ask any partner to confirm which of these inputs it expects you to supply and which it will prepare.

Duration is set by the number of dependencies to test, the number of owners who must review results, and how many test cycles each fix needs. Each dependency generally needs at least one run that records the expected output, one run on the target platform, and a comparison of the two. Shared templates and long approval chains add cycles. Ask for a timeline tied to a named list of dependencies, and ask what happens when a dependency is found to be unsupported, because the answer often changes the schedule more than the testing does.

A written scope should name the inventory method, the list of applications and macros in scope, the test environments, the COLEAT coverage check, the document fidelity tests, and the deliverables with their format. It should also state what is excluded, such as rewriting business logic or changing the source applications, and who decides how an unsupported call is handled. Ask how the scope handles new dependencies found during testing and how changes are priced. DeployOpen works from a fixed-scope written agreement agreed before work starts, so the scope document is where these points should be settled.