The Woes of Munich's Linux Migration

mikrorechner writes "The H Online has a writeup of the problems encountered by LiMux (Wikipedia entry), one of the most prominent Linux migration projects in the world, trying to introduce free software into the highly heterogenous IT infrastructure of the City of Munich. Quoting: 'Florian Schiessl, deputy head of Munich's LiMux project for migrating the city's public administration to Linux, has, for the first time, explained why migrating the city's computing landscape to open source software has taken longer than originally planned.'" Here is Shiessl's blog, in which he details some of the transition problems.

Comments

Because every project is late

[0racle]

Everyone always underestimates how long anything non-trivial is going to take. In this case it seems like not only were they trying to migrate to a new platform, but also trying to undo every past mistake, oversight and quickly implemented solutions that appeared on the surface to work just fine. That's going to take just a little while to get done.

Re:Because every project is late

[WrongSizeGlass]

Indeed.

Every major project always takes longer than expected because so many small details are exposed as you uproot any existing system or workflow process. Instead of looking at this as something that may have been "more trouble than they bargained for" we should learn from it and understand that migrating to Linux won't be any easier than migrating to or from any other platform. I think there are two things to take away from Munich's Linux migration:
* It can be done.
* Being on the leading edge carries with it a lot of responsibility to those who will follow you.

Re:Because every project is late

[Locutus]

but it sounds like most of the problems were due to underestimating how many non-standard development tools and products were used and the trouble getting those over to GNU/Linux. Many of them required either the original vendor to port to an open standard or replacing the existing product with one which was based on open standards. The first option meant that most likely a Microsoft Partner Program member would have to be hired to provide the same product for the GNU/Linux clients. This might normally be an easier option except being a _Microsoft Partner_ often times means you are not allowed to work on other platforms. So the 2nd option is most likely their only choice and that is more expensive in that it would require all users to change the underlying software they currently use for the task.

All in all, this sounds like confirmation that Microsoft's strategy of proprietary API's and patented IP was successful in making it costly to leave their platform. It also shows that it is not impossible and in the long run, it will probably be shown that getting off the Microsoft treadmill might be expensive up front but over time, become very cost effective. Rip and Replace most often ends up resulting in a better, faster, cheaper solution when managed well.

LoB

Bad title is bad.

[Statecraftsman]

I recommend to read the blog as it's more informative and it's also rather optimistic. Not just woes as the title would lead you to believe. Of course making the switch to free software takes work, but it's a great opportunity for constant improvement and as Mr. Shiessl points out, there is much digital waste to be cleaned up on exit from the proprietary.

Re:Bad title is bad.

[MozeeToby]

Very true, by the sound of the blog most of their problems stem from how poorly the systems were managed before. Different versions of Windows running different levels of updates; hundreds of authorized apps, many with overlapping or duplicate functionality; unauthorized applications that had made their way into the work-flows without being documented; proprietary software that didn't follow open standards. I wonder how much of their effort has gone into just getting their infrastructure should have been before the transition even started.

Re:Bad title is bad.

[mikrorechner]

OP here. I have to defend kdawson this time - he just posted what I submitted.

Myself, I'm certainly no Microsoft shill - I'm a Linux proponent, and interested in the LiMux project because I live in Munich.

If the title seems overly negative, I apologize - I'm no native speaker and might have chosen the wrong words.

Re:I find this interesting

[Todd Knarr]

It's not ambiguous in the spec, it's undefined in the spec. But one thing is defined in the spec: a way to do application-specific spreadsheet formulas without breaking the standard and without conflicting with a standardized way of expressing formulas when it's finally standardized. The expectation is that applications will do formulas their own way, possibly recognizing other application-specific formulas (there actually aren't that many different formats). When formulas are finally standardized applications will begin using the standard and will convert any non-standard formulas they recognize into the standard form when the spreadsheet's read in, resulting in a quiet upgrade to the standard form.

And in the meantime, ODF can be used for things like word-processing documents that don't require formulas without having to wait for one spreadsheet-specific feature to be completed.

Re:We thought about doing this in Canada

[WrongSizeGlass]

But we couldn't find a catchy pun or play on words to name the project, so we ditched it altogether.

Really? What about "Canux"? Isn't that already your nickname?

Wrong approach

[Sub Zero 992]

Well, they tried a horizontal migration strategy, moving from location to location and department to department. That meant the problems never stopped.

A better approach might have been to do a vertical top-down migration: Servers: first roll out a directory server infrastructure, then a CIFS strategy etc.; Clients: migrate away from MSIE / Active X, then to CUPS, then away from MS Office etc.. And then, finally, to change the desktop OS out from underneath.

A suggested strategy for those planning something similar: 1: migrate the server services (and create a shiny new unified and consistent infrastructure); 2: migrate the desktop apps to FOSS alternatives (chose apps which will work under your target desktop OS); 3: switch out the desktop OS for linux (the users retain the apps they have become used to).

Just my 0,02

Similar stories

[diegocg]

Regional government of the autonomous community of Valencia (Spain) also switched to free software, last year they released a detailed report (english) of the problems they found and how they fixed it. It took a lot of time to complete it (4 years) and they still depend on propietary software for some systems. These migrations need a lot of work...

Re:how much did this all cost?

[sammyF70]

They aren't trying to make "everything work like it did before with the same functionality". They could have

We could have switched to linux clients in just a few months, giving the order to all 21 IT units to set up a linux client until end of 2008. No further specifications, no standardization and no consolidation. I’m pretty sure they would have done this excellent and then I would have published great news in 2007 or 2008 “LiMux done, Munich completely on free software”.

but the aim is/was to move from a very heterogeneous network (in terms of used OS and software solutions) to some overall standard, which is why it takes so long.

Can I still keep my geek card if I actually read TFA?

Perspective

[Locke2005]

How does this compare to the problems experienced by people migrating 15,000 clients running various Windows releases to Windows 7? Is migrating to Linux more or less costly than migrating to the latest release out of Redmond?