A term is reappearing on many roadmaps: digital sovereignty.

Political pressure is increasing – partly because the EU Parliament is demanding more independence from US infrastructures and more European Open Source Software (OSS). At the same time, the debate shows: this isn’t about symbolic politics, but about risk and cost management in IT operations – especially where a transition doesn’t happen “on a greenfield site” but in the middle of ongoing business.

This article explains how we at do IT smart. implement OSS migrations in real, heterogeneous environments: without big-bang, without productivity disruption – and with transitional operations that work for admins as well as decision-makers.

Why This Topic Is Heating Up Now

We currently see three main drivers:

1) Legal & Compliance

Global provider structures bring topics like the CLOUD Act or transatlantic disputes around regulation (e.g., Digital Services Act (DSA)) onto the agenda – sometimes regardless of whether you use “cloud” or not.

2) Costs & Dependencies

With licenses, data egress, support commitments, and roadmap dependencies, classic vendor lock-in effects emerge.

3) Procurement & Standards

Politics and public administration are increasingly discussing open standards and interoperability – including “Public Money, Public Code.”

The Practical Reality: Migration Rarely Happens “Cleanly” or “In One Step”

Many organizations today are a mix of:

  • Windows/Linux servers, legacy applications, specialized procedures
  • Multiple identity worlds (AD, LDAP, cloud identities)
  • Mail/groupware, file shares, collaboration, telephony, clients
  • Cloud and on-prem components, often in parallel

This is precisely where migrations often fail – not due to technology, but due to transitions: permissions, identities, data flows, specialized applications, operational processes.

Our guiding question is therefore not: “How do we replace everything?” But rather: “How do we reach our goal without endangering operations?”

Our Approach at do IT smart.: “Gentle Migration” Means “Stable Continued Operations”

1) Inventory + Making Dependencies Visible

We don’t start with tool debates, but with clarity:

  • Which systems are critical?
  • Where is data located? What data flows exist?
  • Which contracts/licenses bind you?
  • Which interfaces are mandatory?

Result: a prioritized migration map (quick wins, medium-term, long-term).

2) Target Architecture That Allows Transitions (Instead of “Perfect or Nothing”)

We plan so that hybrid operation is possible – without becoming a permanent state.

Typical: open formats, standardized APIs, clean network and identity boundaries.

3) Identity First – Because Everything Depends on It

Stable identities are the key. We build or consolidate an Identity Provider (IdP) so that Single Sign-On (SSO) works in both old and new worlds.

This “decouples” migrations: you can switch systems without reinventing user management each time.

4) Data Migration Without Surprises

We migrate data incrementally, with verification routines (spot checks, hashes, permission mapping).

Important: The plan always includes rollback and fallback, not just “go live.”

5) Operations & Security as First-Class Requirements

“It runs” isn’t enough. We deliver:

  • Monitoring/alerting, backups, restore tests
  • Patch and update strategies
  • Permission models, logging/auditing
  • Clear responsibilities during the transition phase

6) Cutover Without Downtime, Where Possible

When the use case allows, we use zero-downtime patterns, such as Blue/Green.

If not possible: defined maintenance windows, communication, restart plans.

Typical Migration Paths (Practical, Without Dogma)

Depending on the organization, we choose sensible entry points:

  • Collaboration / Files / Groupware: first partial areas, then broader rollout
  • Virtualization/Compute: e.g., KVM-based platforms, then workload migration
  • Dev/CI: Reproducible builds, artifact handling, secrets, deployments
  • Monitoring/Logging: Create transparency before rebuilding

The common thread: Migration in stages, with measurable criteria (stability, costs, risk, user feedback).

What Decision-Makers Get From This (Without IT Fairy Tales)

  • Predictable costs instead of license/roadmap surprises
  • Risk reduction through fewer dependencies and transparent operations
  • More negotiating power (including with service providers)
  • Knowledge in-house: documented architecture, processes, runbooks

How We Work

do IT smart. speaks both languages: operations/administration and management/strategy.

  • For admins: clear technical paths, smooth transitions, stable operational models
  • For decision-makers: comprehensible roadmaps, risks, costs, compliance, priorities

If you’re facing an OSS transition – or “just” want to properly assess dependencies and options first – a joint workshop is a good start: current state, target architecture, migration paths, effort/costs/risk.

Sources & Further Reading