File Format Interoperability with Microsoft and LibreOffice Files

Google Workspace

Chapter 8 · File Format Interoperability with Microsoft and LibreOffice Files

LibreOffice Chapter 9 covered interoperability between two genuinely different FILE formats — ODF and OOXML. This chapter is a structurally different question, foreshadowed since Chapter 1: what happens when a real file is converted into a cloud-native object that, per Chapter 1, isn't a file at all anymore — and what happens going the other direction.

A Genuinely Different Kind of Conversion

LibreOffice's own interoperability question was file-to-file: .docx in, .odt out, both still genuine files the whole time. This chapter's question has an extra wrinkle Chapter 1 already set up: converting into Google Workspace means a file stops being a file at all, becoming a live cloud object instead — and converting back out means generating a brand-new file from something that, moments before, had no file behind it.

Uploading a Microsoft or LibreOffice File

Uploading a .docx, .xlsx, .pptx, .odt, .ods, or .odp file to Google Drive offers two genuinely different paths: opening and editing it directly while it stays closer to its original format (sometimes called Office compatibility mode), or explicitly converting it into a true, native Google Doc/Sheet/Slide via File → Save as Google Docs/Sheets/Slides. These are meaningfully different outcomes, not two names for the same thing.

What Happens During the Conversion

Once genuinely converted to native Google format, the overall pattern is similar to LibreOffice Chapter 9's own framing: most everyday content — text, standard formatting, common formulas, ordinary slide content — survives reasonably well. The specific risk areas worth knowing here: VBA macros do not transfer in any form (Chapter 7's own point, restated in this specific context); elaborate custom PowerPoint animations or deep theme customization may simplify (Chapter 6's own forward-reference, now addressed directly); and some advanced Word field codes or Excel-specific features may have no direct equivalent in Google's own feature set.

Exporting Back Out

File → Download works from any Google Doc, Sheet, or Slide, offering Microsoft formats, ODF formats, and PDF, directly. This is the reverse conversion — generating a genuine file from a cloud-native object that, until that moment, had no file behind it at all, exactly the same "Download creates a separate, disconnected copy" behaviour Chapter 1 first established, just now producing a file in whichever format is actually needed.

The "Office Compatibility Mode" Middle Ground

Worth being clear about: opening an uploaded Microsoft file without explicitly converting it lets you view and edit it while it stays closer to its original format, rather than becoming a genuine native Google Doc immediately — a real third option sitting between "still just a file, untouched" and "now a fully native cloud object." It's a reasonable choice when you specifically want to avoid a full conversion, but it's still worth understanding it's a distinct middle path, not simply "the same as opening any other file."

LibreOffice Chapter 9's questionThis chapter's question
What's on each sideTwo genuinely different FILE formatsA file on one side, a cloud-native object on the other
The underlying riskTwo formats representing overlapping but not identical featuresThe same, plus one side isn't a file at all
MacrosVBA and LibreOffice Basic don't transferVBA and Apps Script don't transfer (Chapter 7)
Going "back"Saving in the other file formatFile → Download, generating a fresh file from a cloud object
Recognising which kind of interoperability question you're actually facing
This entire subject has now covered three distinct interoperability situations: Excel and Word & PowerPoint's own native formats (no conversion needed at all), LibreOffice's file-to-file conversion (Chapter 9 there), and this chapter's file-to-cloud-object conversion. Recognising which one actually applies to a given situation — and in particular, whether one side of the conversion is even a file in the first place — determines which specific risks are worth checking for.
Office compatibility mode does not preserve macros either
It's tempting to assume that opening a file in the "closer to original" compatibility mode, rather than fully converting it, might preserve more of the original file's behaviour — including its VBA macros. It does not. Regardless of which upload path is used, VBA macros do not run in Google Workspace in any form, exactly as Chapter 7 established — compatibility mode affects how closely the visible formatting and structure resemble the original file, not whether embedded automation code executes.

Hands-On Exercises

Exercise 1

Upload a .docx file to Google Drive containing standard text and formatting, but no macros or unusual features. Convert it to a native Google Doc. Based on this chapter, predict whether this specific conversion is likely to cause visible changes, and explain your reasoning.

📄 View solution
Exercise 2

A colleague uploads a .xlsm workbook containing VBA macros and opens it in "Office compatibility mode" specifically because they assumed this would keep the macros working. Explain why this assumption is incorrect, referencing this chapter's own warning box.

📄 View solution
Exercise 3

Explain, in your own words, why converting a .pptx file into a native Google Slides presentation is a genuinely different KIND of interoperability question than LibreOffice Chapter 9's own .pptx-to-.odp conversion, even though both situations involve moving content between two different presentation tools.

📄 View solution

Chapter 8 Quick Reference

  • This chapter's interoperability question is file ↔ cloud object, structurally different from LibreOffice's own file ↔ file question
  • Uploading offers two paths: Office compatibility mode (stays closer to the original) or a full conversion (Save as Google Docs/Sheets/Slides)
  • Most everyday content survives conversion well; VBA macros, elaborate custom animations, and some advanced field codes are the real risk areas
  • File → Download is the reverse conversion — generating a fresh file from a cloud object that had none
  • Compatibility mode does not preserve VBA macros — nothing preserves them; they require a genuine Apps Script rewrite (Chapter 7)