Tool for analyzing Office documents before LibreOffice migration

English
, , , ,
#1

Hi all,

I hope this is okay to post here – I just created this account.

I’ve been working on a small tool for Office migrations and thought it might be relevant for some of you here.

The idea is pretty simple:
before migrating large document collections (Word, Excel, PowerPoint), the tool analyzes the documents and tries to detect potential compatibility issues in advance.

I noticed in a few projects that conversion itself often “works”, but problems show up much later when documents are opened again.

So this is more about understanding the document base before migration, not about converting.

It’s still very early and I’m honestly just looking for feedback, especially from people who have experience with LibreOffice migrations.

If anyone is curious:

Thanks :slightly_smiling_face:

#2

Why would anyone need to “migrate large document collections” - and what does that mean exactly: by “migration”, do you mean “conversion”?

No one should ever do mass-conversion of large document collections. At all. Doing that inevitably creates conversion problems. The documents should stay in the format they were authored initially - until the day you need to edit it. Then you take that single document, save in the native format for the application you are using (here: ODF), check the possible conversion issues (you are working with it now, and it’s a single document, so you can do that), and continue working. As a nice bonus, this gives you all the improvements that we implement between the time you initially started to use LibreOffice (and installed some version of it), and the time you decided to convert this single document (using a newer version that you installed later).

Any tool that promotes mass conversion is IMO harmful, because it provokes irreversible data loss that goes without notice. No matter how much care you put into your “check incompatibilities” tool, you can’t be sure you caught all possible problems (including bugs), that may make the conversion of a given document completely broken.

I mean, that the LibreOffice’s own built-in conversion wizard is also harmful.

Convert WORD Docs to LibreOffice Documents?
#3

Hi, thanks for your detailed reply – I actually agree with your core point.

Ideally, documents should not be mass-converted blindly. Keeping original formats and converting only when needed is definitely the safer approach.

The problem I’ve seen in practice is that many organizations still do large-scale migrations – not because it’s technically ideal, but because of:

  • system changes
  • policy decisions
  • cost or licensing pressure
  • document management constraints

So the question becomes less “should we migrate everything?” and more:

“How do we understand the risks if someone decides to do it anyway?”

DocStable is explicitly not a conversion tool.

It’s meant as a decision support tool to analyze document collections before any migration is started, so that risks are visible upfront.

In other words:
not “convert everything”,
but “know what you’re dealing with first”.

I fully agree with you that silent data loss is the real danger – that’s exactly what I’m trying to make visible earlier.

Curious how you usually approach large document collections in practice?

#4

One thing first: If this will become a thread for discussion, please use the speech-bubble instead of the “answer” button. On this site “answers” can be re-organizedvto have the most upvoted one on top. Makes discussions unreadable. Comments are in the order theey were added.

Backup, then set the folder(s) or files read-only to prevent the files being directly “used”.
.
My main point is to find out first

  • what is needed only as archive but “never” used
  • what needs to be searchable (document itself) or only possible to find (based on information in a database). Example: external questions to reprint older invoices.
  • documents to convert or replace like templates
1 Like
#5

Document management constraints is the only actual reason (but I would be curious to see a document management system that disallows DOC(X)/PPT(X)/XLS(X), but accepts ODF…). The others are not real reasons, but misconceptions (changing systems, licenses, etc. can’t force you to convert document formats; policy decisions that mandate so are themselves misguided).

I hope that your tool will end its analysis with a big warning “there may be, and that’s most likely, other issues not detected by the tool. Consider avoiding the mass conversion for the following reasons …”.

Personally myself - keeps them in the original formats.

#6

@Wanderer
Thanks for the hint regarding comments vs. answers – appreciated, I’ll follow that :+1:

And yes, that actually aligns very well with what I’m seeing in practice.

The initial classification you describe is exactly the critical step:

  • archive vs. active use
  • searchable vs. only retrievable
  • templates vs. static documents

What I often observe, though, is that this classification is done without really knowing the technical characteristics of the documents.

That’s where I see the gap:
You decide what to do before fully understanding what you have.

The idea behind DocStable is to add that missing layer:
analyzing the documents first (structure, complexity, potential issues), so that decisions like “archive / convert / leave untouched” can be made on a more informed basis.

So not replacing your approach — but supporting it with additional transparency.

Would be interesting to hear:
Do you currently rely purely on metadata / process knowledge for that classification, or do you also inspect document structure in some way?

#7

@mikekaganski
Thanks for your perspective – I actually don’t disagree with the principle.

Keeping documents in their original formats is definitely the safest approach from a technical standpoint.

Where I see the gap is between “what should be done” and “what actually happens in organizations”.

In many real-world cases, decisions are made at a higher level (procurement, strategy, compliance), and technical best practices are not always the driving factor. So even if we agree that mass conversion is not ideal, it still happens.

That’s exactly the situation I’m trying to address.

And yes – I fully agree with your point about limitations.

Any analysis tool must assume that it cannot detect everything. The intention is not to provide false certainty, but to reduce blind spots and make risks more visible before decisions are made.

So rather than encouraging conversion, the idea is:
–>> make the consequences more transparent
–>> and in some cases, even support the argument against conversion

Your approach (keeping original formats) is actually one of the possible outcomes I would consider a “good decision”.

Out of curiosity:
In environments where documents are shared across systems or teams, how do you handle compatibility or long-term accessibility?

Cheers Ralph

#8

In my opinion, this is also a requirement of German laws, such as the Abgabenordnung (AO), insofar as it concerns commercial matters:
https://www.gesetze-im-internet.de/ao_1977/__147.html

#10

The main issue is the difference in document model between both suites. And there is immediately a psychological bias because the models have a decent intersection, naively suggesting they are equivalent.

Unfortunately, no tool can enough highlight this difference. And it is aggravated by in-house writing rules which customise the way to use the model (selecting preferred constructs).

Migration goes much beyond simple conversion. In my understanding, migration posits that you understand the models and propose an agreed workflow on how to write or rewrite the “conflicting” constructs.

But the real weak point is staff. Most people use office programs without really caring for the underlying document model. Even existing to-be-migrated documents are not written according to the best standard: they are written “intuitively”, i.e. without having read the manual, working “as had always been done without problems”. Even if you train people to the “subtleties” of the new suite, you won’t help to change routine. What worked in the past (even if not optimal) is “good” (combat-proven in military terms). As the proverd says, you don’t change a winning team.

So, unless you can deeply prepare minds and make them accept willingly the change, I am extremely pessimistic about the success of a “migration”.

That said, I adhere to @Hrbrgr’s approach.

#12

@ajlittoz
That’s a very insightful point - especially regarding the document model and the psychological aspect.

I fully agree that migration is not just a technical process, but a conceptual and organizational one. The differences in document models are often underestimated, precisely because of the visible overlap.

And your point about user behavior is probably the most critical one.

In many environments, documents are not created based on a clear model or standard, but rather on habit. That makes any migration much more unpredictable, because you are not just dealing with formats, but with accumulated “implicit practices”.

That’s actually where I see one practical challenge:

Even if we accept that successful migration requires understanding models, workflows, and user behavior - in reality, decisions are often made without having a clear picture of what is actually inside the existing documents.

My approach is not to solve the human or organizational side of migration (which is probably the hardest part), but to at least make the current state more visible and less opaque.

So not replacing training or process definition - but reducing uncertainty about the starting point.

And I agree with your overall conclusion:
without preparation and acceptance, migration will always be difficult.

Thank you,
Ralph

#14

@Hrbrgr
Good point, thanks for bringing that up.

Yes, especially in Germany, legal requirements like §147 AO (and also GoBD) make it very clear that original documents must be preserved in a way that ensures integrity and auditability.

That’s actually another aspect where I see a need for more transparency in practice.

Even if organizations decide to introduce new systems or formats, they still need to understand:

  • which documents are legally relevant
  • which must remain unchanged
  • and where transformations could become problematic from a compliance perspective

This is another angle I’m trying to address:
not just technical risks, but also helping to make more informed decisions in regulated environments.

So in many cases, “do not convert” is not only technically safer - but also legally required.

Appreciate the reference :+1::+1::+1:
Cheers, Ralph

#15

And the tools for assessing risks can only reflect the state of affairs at the time the tool was created. See also:

How to open files from MS-Office 2007 or 2010 (.DOCX, .XLSX,…)?

#16

Yes, I see your Point and you are definitely right.

And I would even agree that any tool can only reflect a snapshot - the state of knowledge at a given time, including its own limitations and potential blind spots.

Also the examples you linked show quite well how complex and dynamic compatibility actually is. Especially with changing document models, versions and even “compatibility modes”, there is no such thing as a stable, fully predictable target.

That’s exactly why I’m not trying to “guarantee” anything with analysis.

For me, the key issue is different:

Right now, many decisions are made with almost zero visibility into the actual document landscape.

So it’s not:
“perfect analysis vs imperfect analysis”

but rather:
“no understanding vs better understanding”

Even if the analysis is incomplete (which it always will be), it can still reduce blind spots and highlight patterns - especially in large collections where manual inspection is simply not feasible.

And in some cases, that might even support the decision to not convert at all.

So I see it less as “the tool knows everything”, and more as:
“the tool helps you see more than before”.

#17

Then I hope you enjoy it, and please also take a look at the LibreOffice blog.
Find all the posts on the topic of ODF (around 20-30 posts):
https://blog.documentfoundation.org/

EDIT:
I just noticed using the search function that there are 49 posts so far!

1 Like
#18

Thanks, appreciate it :+1:

Will take a look at the blog - sounds interesting.

#13

Yes, you’re right, sorry

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.