Migration Guide – Transitioning to openDesk Edu

Introduction

University IT landscapes are complex. Over decades, institutions accumulate a patchwork of on-premise servers, self-hosted groupware, legacy learning management systems, and proprietary collaboration tools — each with its own authentication source, storage backend, and administrative interface. The operational cost of maintaining this heterogeneity grows year over year, while pressure mounts to meet data sovereignty requirements, reduce vendor lock-in, and provide a modern, integrated user experience.

openDesk Edu addresses these challenges by providing a fully integrated, Kubernetes-based collaboration platform tailored for the higher education sector. It bundles email and calendaring (Grommunio, OX App Suite, SOGo), file sync and share (Nextcloud, OpenCloud), learning management (ILIAS, Moodle), video conferencing (BigBlueButton, Jitsi), collaborative editing (Collabora, Etherpad, CryptPad, Excalidraw), project management (OpenProject, Planka), ticketing (Zammad), wiki and knowledge base (XWiki, BookStack), and more — all behind a unified identity layer built on Keycloak with SAML federation to DFN-AAI and eduGAIN.

This guide covers four common migration scenarios:

Scenario	Description
Greenfield	No prior groupware or LMS; deploying openDesk Edu for the first time
Rip-and-replace	Shutting down legacy services and moving data in a planned cutover window
Phased migration	Migrating service by service, running old and new in parallel
Hybrid federation	Keeping an existing IdP and federating openDesk Edu behind it

The guide is written for university IT administrators and system engineers. It assumes familiarity with DNS, LDAP, IMAP, SAML, and basic Kubernetes operations.

Pre-Migration Assessment

A thorough assessment of the current infrastructure is the single most important factor in a successful migration. Rushing this phase causes downstream failures that are exponentially harder to fix.

Service Inventory

Begin by cataloguing every service currently in use. For each service, document:

• Vendor and version — determines migration tool compatibility
• User base — number of active users, groups, distribution lists
• Data volume — mailbox sizes, file storage usage, LMS course data
• Authentication method — LDAP bind, SAML SP, OIDC, local accounts
• Integration points — APIs, webhooks, LTI links, SSO sessions
• Deprecation status — is the vendor still supporting this version?

Create a table similar to the one below:

Service	Users	Data Volume	Auth	Integration	Migratable?
Microsoft Exchange	15,000	4.2 TB	AD/LDAP	EWS, ActiveSync	Yes (IMAP/EWS)
ILIAS 7	12,000	850 GB	Shibboleth SP	LTI 1.3	Yes (SCORM/backup)
ownCloud 10	8,000	6.1 TB	LDAP	WebDAV	Yes
Jitsi (self-hosted)	5,000	—	none (open)	—	Configuration only

User Count and Data Volume Estimation

Obtain exact figures rather than estimates where possible. Run SQL queries against your IdP directory, mail server databases, and file storage backends. For mail, report both mailbox count and total mailbox size — a university with 20,000 mailboxes averaging 200 MB has very different characteristics from one with 5,000 mailboxes averaging 4 GB.

Use these figures to size the openDesk Edu Kubernetes cluster. As a rule of thumb:

• Control plane nodes: 3 (for HA)
• Worker nodes: Start with 5–7, scale based on load
• Storage: Plan for 1.5× current data volume to account for growth and migration buffers
• Memory: 8–16 GB per worker node minimum for the collaboration services

Identity Provider Audit

Identify every source of truth for user identities:

• Active Directory / LDAP — most common, often the authoritative source
• SAML federation — DFN-AAI, eduGAIN, or national research networks
• OIDC providers — Azure AD, Google Workspace, or custom solutions
• Local databases — legacy applications with independent user tables

Determine which system is authoritative. The IdP migration strategy (Option A or B in the next section) depends on whether you can replace or must wrap the existing provider.

DNS and TLS Inventory

Perform a complete DNS audit:

• List every DNS zone and subdomain associated with university services
• Document current TTL values (they must be lowered before cutover)
• Identify all TLS certificates, their issuers, and expiry dates
• Note any DNSSEC configuration that may affect cutover timing

Services that typically have their own DNS entries include: mail, webmail, cloud, lms, meet, wiki, pad, project, ticket, auth, sso, api, autoconfig, mta-sts, _dmarc, _smtp._tls, _imap._tls.

Network Requirements

During migration, the old and new infrastructure will run in parallel. Ensure the following network paths exist:

• IMAP/EWS sync: openDesk Edu workers → legacy mail server (ports 143, 993, 443)
• LDAP sync: Keycloak → legacy LDAP/AD (port 389, 636)
• Database replication: if keeping a read replica for verification
• Reverse proxy: external traffic must be routable to both old and new ingress controllers during phased cutover
• DNS management: API access to your DNS provider for automated record updates

Identity Provider Migration

Keycloak is the central identity and access management component of openDesk Edu. It handles authentication, authorization, user federation, and SAML/OIDC bridging to upstream identity federations.

There are two primary migration approaches:

Option A: Replace Existing IdP with Keycloak

This approach makes Keycloak the authoritative identity provider. User credentials are migrated into Keycloak, and Keycloak federates to DFN-AAI/eduGAIN for external access.

Export Users and Groups from AD/LDAP

If your legacy directory is Active Directory or OpenLDAP, you have two choices:

1. LDAP federation (recommended): Configure Keycloak to connect to your existing LDAP directory as a user federation provider. This avoids bulk export/import and keeps the directory as the user source of truth. Group mappings and role assignments are synchronized live.
2. Bulk import: Use ldapsearch to export users and groups to LDIF, then import into Keycloak's built-in user store. This is useful when the legacy directory will be decommissioned.

Example LDAP federation configuration in Keycloak:

# Keycloak LDAP federation provider configuration
provider: ldap
consoleDisplayConnectionUrl: ldaps://ldap.example.edu:636
usersDn: ou=people,dc=example,dc=edu
bindDn: cn=keycloak,ou=service,dc=example,dc=edu
bindCredential: <secret>
customUserSearchFilter: (objectClass=inetOrgPerson)
searchScope: one
priority: 0
editMode: READ_ONLY
syncRegistrations: false
vendor: active_directory
useKerberosForPasswordAuthentication: false

Import into Keycloak

If you choose bulk import, the general workflow is:

1. Export users from the legacy directory to LDIF
2. Use Keycloak's Import Users feature via the Admin Console or the kcadm.sh script
3. Set temporary passwords or force password change on first login
4. Migrate group memberships and role assignments

# Example: bulk import users using kcadm.sh
kcadm.sh create users -r university \
  -s username=jdoe \
  -s email=jdoe@example.edu \
  -s firstName=John \
  -s lastName=Doe \
  -s enabled=true \
  -s attributes='{"eduPersonPrincipalName":["jdoe@example.edu"]}'

Configure SAML Federation with DFN-AAI/eduGAIN

Keycloak acts as a SAML Identity Provider for your internal services while also acting as a SAML Service Provider to upstream federations.

<!-- Keycloak SAML SP descriptor for DFN-AAI -->
<md:EntityDescriptor entityID="https://auth.example.edu/auth/realms/university/broker/dfn-aai/endpoint">
  <md:SPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <md:AssertionConsumerService
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
      Location="https://auth.example.edu/auth/realms/university/broker/dfn-aai/endpoint"
      index="1"/>
  </md:SPSSODescriptor>
</md:EntityDescriptor>

Register this metadata with your national federation operator. Once approved, users from other federated institutions can log in to your openDesk Edu services via their home institution credentials.

Password Policies and MFA

Configure password policies in Keycloak to match or exceed your existing requirements:

• Minimum length, complexity, history
• Password expiration (consider semester-based cycles rather than arbitrary 90-day periods)
• Multi-factor authentication: WebAuthn (FIDO2), TOTP, SMS, or backup codes

Enable conditional MFA — for example, require MFA for administrative services but not for basic file access.

Option B: Federate Keycloak Behind Existing IdP

If replacing the university IdP is not feasible (political or operational reasons), deploy Keycloak as a SAML Service Provider behind your existing IdP. In this configuration:

1. Users authenticate against the existing university IdP
2. The IdP sends a SAML assertion to Keycloak
3. Keycloak maps the assertion attributes to its internal user model
4. Keycloak issues its own tokens to openDesk Edu services

This approach is commonly used when the university participates in DFN-AAI and must maintain its existing SAML infrastructure.

Attribute Mapping

Configure attribute mapping between your IdP's SAML assertions and Keycloak's user model:

SAML Assertion Attribute	Keycloak User Attribute
urn:oid:0.9.2342.19200300.100.1.3 (mail)	email
urn:oid:2.5.4.42 (givenName)	firstName
urn:oid:2.5.4.4 (sn)	lastName
urn:oid:1.3.6.1.4.1.5923.1.1.1.6 (eduPersonPrincipalName)	username, epPN
urn:oid:1.3.6.1.4.1.5923.1.1.1.1 (eduPersonAffiliation)	groups

Testing Authentication Before Full Cutover

Before the cutover, test authentication in isolation:

1. Deploy a Keycloak instance (or use the one included in openDesk Edu)
2. Configure federation to your test IdP or LDAP directory
3. Create a test service (e.g., a test Nextcloud instance) configured to use Keycloak OIDC
4. Have a small group of IT staff test login, logout, session refresh, and MFA
5. Monitor Keycloak logs for assertion errors, attribute mismatches, or timeouts

# Test authentication by requesting a token directly
curl -s -X POST https://auth.example.edu/auth/realms/university/protocol/openid-connect/token \
  -d "client_id=test-client" \
  -d "username=jdoe" \
  -d "password=test-password" \
  -d "grant_type=password" | jq .

Only proceed to full cutover once test authentication passes for all user types (staff, faculty, students, external affiliates).

Email Migration

Email migration is typically the most critical and highest-risk part of the transition. Universities run their email infrastructure for decades, and mailboxes accumulate historical data, complex folder structures, delegation rules, and shared mailboxes.

IMAP Sync Strategy with imapsync

imapsync is the de facto standard tool for migrating mail between IMAP servers. It preserves folder structure, flags, and dates.

Preparation

Install imapsync on a machine with high-bandwidth access to both the source and destination servers:

apt install imapsync
# or from source
git clone https://github.com/imapsync/imapsync.git

Batch Migration Plan

Divide mailboxes into batches to manage load and detect issues early:

Batch	Users	Mailboxes	Total Size	Estimated Time
1	IT staff, pilot group	50	25 GB	2 hours
2	Faculty (early adopters)	500	600 GB	24 hours
3	Staff	3,000	2.1 TB	3–4 days
4	Students	12,000	1.5 TB	5–7 days
5	Alumni, shared mailboxes	2,000	800 GB	2–3 days

Running imapsync

imapsync \
  --host1 imap.legacy.example.edu --user1 jdoe --password1 secret \
  --host2 imap.openedesk.edu --user2 jdoe --password2 secret \
  --ssl1 --ssl2 \
  --exclude "Trash|Junk|Spam" \
  --maxsize 52428800 \
  --addheader \
  --logfile imapsync-jdoe.log

Key flags:

• --exclude: Skip trash and spam folders to save time
• --maxsize: Skip messages above a size threshold (50 MB is common)
• --addheader: Adds a header to migrated messages for tracking
• --logfile: Essential for debugging failed transfers

Rate Limiting

Set --maxconnections to avoid overwhelming the source server. Start with 1 connection per mailbox and 2 concurrent mailboxes. Monitor source server CPU and disk I/O:

# Limit to 5 simultaneous transfers
ls mailboxes.txt | xargs -P5 -I{} imapsync --host1 ... --host2 ... {}

Handling Large Mailboxes (>10 GB)

Mailboxes exceeding 10 GB benefit from special handling:

1. Run a preliminary sync to move old data, then an incremental sync for recent changes
2. Use --split1 to split large folders into ranges of messages
3. Increase timeout values with --timeout1 and --timeout2
4. Consider skipping attachments larger than 25 MB and transferring them out of band

# Two-pass sync for large mailboxes
# Pass 1: sync everything older than 30 days
imapsync ... --maxage 30
# Pass 2: sync recent messages (faster incremental run)
imapsync ... --minage 1

Calendar and Contact Migration

Source	Destination	Protocol/Tool	Notes
Exchange	Grommunio/OX	EWS → ActiveSync	Microsoft provides Exchange Migration Tools
SOGo	SOGo (new)	CalDAV/CardDAV	Direct CalDAV sync
Google Workspace	Grommunio/OX	Google Takeout → import	Manual per-user or automated API
iCal/CSV	Nextcloud/OX	CalDAV	Bulk import via scripts

For CalDAV migration, use tools like caldavsync or vdirsyncer:

# Sync a single calendar
vdirsyncer sync calendar-jdoe

# Batch sync for all users
for user in $(cat users.txt); do
  vdirsyncer sync calendar-$user
done

Mail Flow Cutover

The MX record change is the point of no return for email. Execute it carefully.

Lower TTL Before Cutover

48 hours before the planned cutover, lower the TTL of your MX and related DNS records from their default (often 86400 seconds / 24 hours) to 300 seconds (5 minutes):

; Original
example.edu.   86400  IN  MX  10 mail.legacy.example.edu.

; Reduced TTL (48h before cutover)
example.edu.   300    IN  MX  10 mail.legacy.example.edu.

Parallel Mail Flow

Configure the legacy mail server to relay mail for migrated users to the new openDesk Edu mail server. This allows incremental migration without splitting the domain:

# On legacy server: transport map for migrated users
user@example.edu smtp:[mail.openedesk.edu]:25

MX Cutover

When all mailboxes are synced and verified:

; Cutover
example.edu.   300    IN  MX  10 mail.openedesk.edu.
example.edu.   300    IN  MX  20 mail.legacy.example.edu.  ; backup

Keep the legacy mail server as a secondary MX (higher priority number = lower priority) so it accepts mail if the new server is unavailable.

Mailbox Verification After Migration

For each migrated mailbox, verify:

1. Login test: Can the user log in via IMAP and webmail?
2. Folder count: Does the folder hierarchy match the source?
3. Message count: Compare total message count (use SELECT INBOX IMAP command)
4. Recent send/receive: Can the user send and receive new messages?
5. Calendar: Are future appointments present?
6. Contacts: Are all address book entries intact?

# Compare mailbox sizes via IMAP
# Source
curl-imap ... imap.legacy.example.edu
# Destination
curl-imap ... imap.openedesk.edu

File Storage Migration

File storage in openDesk Edu is provided by Nextcloud and/or OpenCloud. Both support WebDAV, which is the primary migration interface.

WebDAV Sync Tools

For medium-scale migrations (up to 10 TB), WebDAV-based tools are sufficient:

# Using davfs2 to mount both source and destination
mount -t davfs https://cloud.legacy.example.edu/remote.php/dav/files/jdoe /mnt/source
mount -t davfs https://cloud.openedesk.edu/remote.php/dav/files/jdoe /mnt/dest
rsync -av --progress /mnt/source/ /mnt/dest/

For large-scale migrations, use rclone which supports multiple backends and provides retry logic:

# rclone configuration for Nextcloud/WebDAV
rclone config
# Sync all files for a user
rclone sync nextcloud_legacy:jdoe nextcloud_openedesk:jdoe \
  --progress \
  --transfers 4 \
  --checkers 8 \
  --retries 3

Large Dataset Migration (>10 TB)

For datasets exceeding 10 TB, bypass WebDAV and sync directly to the storage backend:

1. Mount the legacy storage (NFS, SMB, or local disk)
2. Copy data to the openDesk Edu storage backend (e.g., Longhorn volume, NFS export, or S3 bucket)
3. Re-scan the file system from the application layer:

# Nextcloud file scan after backend copy
sudo -u www-data php occ files:scan --all

Shared Folder and Permission Mapping

Shared folders are the most complex part of file storage migration. Document every share before migration:

# List all shares from Nextcloud
sudo -u www-data php occ sharing:list \
  --output json > legacy_shares.json

After migration, recreate shares using the openDesk Edu API or occ commands:

# Re-create a share
sudo -u www-data php occ sharing:create \
  --share-type group \
  --share-with it-department \
  --path "shared/it-docs" \
  --permissions read

Handling File Versions and Trash Bins

By default, file versions and trash contents are migrated along with the current file data when using WebDAV copy. However, this can double or triple the transfer volume. Decide one of the following:

1. Migrate everything (recommended): Includes version history and trashed files. Use rclone with --include "*/versions/*" and --include "*/trash/*".
2. Start fresh: Only migrate current files. Users lose version history but migration is faster.
3. Hybrid: Migrate current files and versions from the last 30 days only.

Verification

After migration, verify file storage integrity:

Check	Method
File count	`find /storage -type f
Total size	du -sh /storage
Permission spot-check	Select 50 random folders, compare share settings
File content spot-check	md5sum on 100 random files, compare with source
User login test	Log in as 10 random users, confirm file listing

LMS Migration (ILIAS, Moodle)

Learning Management Systems contain years of course content, student submissions, gradebooks, and activity data. Migration must be planned around the academic calendar.

Course Content Export/Import

ILIAS

# Export a single course
# Via ILIAS GUI: Administration > Export > SCORM
# Or via CLI:
php setup/ilias.php export \
  --type course \
  --ref_id 12345 \
  --target /tmp/export

# Import into openDesk Edu ILIAS
# Via GUI: Administration > Import

ILIAS supports SCORM 1.2 and 2004 export. Not all ILIAS plugins export cleanly — test with a representative course first.

Moodle

# Moodle course backup via CLI
sudo -u www-data php admin/cli/backup.php \
  --courseid=123 \
  --destination=/tmp/moodle-backup \
  --pref-role --pref-user --pref-activity

# Restore
sudo -u www-data php admin/cli/restore.php \
  --backupfile=/tmp/moodle-backup/backup-moodle2-course-123.mbz \
  --courseid=0 \
  --categoryid=1

User Gradebook Preservation

Gradebooks must be exported separately from course content:

# ILIAS: export gradebook to CSV via GUI or SOAP API
# Moodle: grade export via CLI
sudo -u www-data php grade/export/grade_export.php \
  --course=123 \
  --format=csv \
  --output=/tmp/grades-course-123.csv

Import gradebooks after course migration using the platform's import functionality. Note that assignment IDs and quiz IDs may change, which can break grade-to-activity linkages. Manual mapping is often required.

LTI Integration Reconfiguration

If your university uses LTI 1.3 to connect LMS platforms with external tools, every tool link must be reconfigured after migration:

1. Document all existing LTI 1.3 platform deployments and tool registrations
2. Generate new platform keys in the new ILIAS/Moodle instance
3. Re-register tool deployments with new platform IDs and public keysets
4. Test a sample of LTI launches before full cutover

Plugin Compatibility Assessment

Plugin	ILIAS	Moodle	Notes
H5P	Bundled	Bundled	Data migratable
BigBlueButton	Plugin	Plugin	Reconfigure endpoint
Turnitin	—	Plugin	Re-activate with new instance URL
MathJax	Plugin	Bundled	Configuration only
Custom auth	Plugin	Plugin	Replace with Keycloak OIDC

Migration Time Window Planning

Critical: Plan LMS migration during a semester break or between academic terms. Allow a minimum of two weeks for migration and one week for verification before the next term begins.

Semester	Recommended Window	Duration
Summer break (July–September)	Mid-August	3 weeks
Winter break (December–February)	Early January	2 weeks
Spring break (March–April)	Late March	1 week (tight)

Video Conferencing Migration

BigBlueButton

BigBlueButton migration involves recordings (stored on disk) and API user data:

# Copy recordings
rsync -av /var/bigbluebutton/published/ \
  new-server:/var/bigbluebutton/published/
rsync -av /var/bigbluebutton/unpublished/ \
  new-server:/var/bigbluebutton/unpublished/
rsync -av /var/bigbluebutton/recording/raw/ \
  new-server:/var/bigbluebutton/recording/raw/

# Rebuild recording metadata on the new server
bbb-record --rebuildall

API user data (meeting creation permissions, hooks) is stored in the database. Export the meeting and user tables from PostgreSQL and import into the new instance.

Jitsi

Jitsi room state is ephemeral (stored in Prosody/XMPP memory). There is no room data to migrate — rooms are created on demand. Only configuration needs to be moved:

• config.js: branding, authentication settings
• prosody.cfg.lua: domain and authentication
• Custom meeting URL patterns

Meeting URL Redirection

During transition, configure URL redirects from the old video conferencing domain to the new one:

# Nginx redirect for old meeting URLs
server {
  server_name meet.legacy.example.edu;
  return 301 https://meet.openedesk.edu$request_uri;
}

DNS and Domain Cutover

The DNS cutover determines when users start hitting the new infrastructure. Execute it methodically.

Step-by-Step DNS Change Plan

1. T-48h: Lower TTL on all affected records to 300 seconds
2. T-24h: Announce cutover window to all users
3. T-0h (Auth cutover): Change Auth/CNAME records to point to openDesk Edu Keycloak
4. T+1h (Mail cutover): Change MX records
5. T+2h (File cutover): Change cloud CNAME
6. T+3h (LMS cutover): Change lms CNAME
7. T+4h (Conferencing cutover): Change meet CNAME
8. T+48h: Raise TTL back to normal values

Low-TTL Preparation

# Before cutover (T-48h)
nsupdate << EOF
server ns1.example.edu
zone example.edu
update delete example.edu. MX
update add example.edu. 300 MX 10 mail.legacy.example.edu.
send
EOF

Cutover Sequence

Cut over authentication first, then services in order of dependency. Email should be cut over as early as possible because MX propagation takes time even with low TTL.

Monitoring DNS Propagation

Use dig to monitor propagation globally:

# Monitor from multiple resolvers
for ns in 8.8.8.8 1.1.1.1 9.9.9.9; do
  dig @$ns MX example.edu +short
  sleep 1
done

# Check a specific record type
dig +short MX example.edu
dig +short A auth.example.edu

TLS Certificate Re-Issuance

After DNS cutover, re-issue TLS certificates for the new infrastructure. openDesk Edu supports two approaches:

1. openDesk Certificates (Bundesdruckerei): For German universities requiring qualified certificates
2. Let's Encrypt: Automated issuance via cert-manager in Kubernetes

# cert-manager ClusterIssuer for Let's Encrypt
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: it-admin@example.edu
    privateKeySecretRef:
      name: letsencrypt-prod-key
    solvers:
    - http01:
        ingress:
          class: nginx

Rollback Plan

Despite best efforts, some migrations need to be reversed. Prepare for this before cutover, not after.

Keep Old Infrastructure in Read-Only Mode

Keep the legacy infrastructure running in read-only mode for at least 30 days after cutover. This means:

• Mail server: Accept mail but reject SMTP authentication; relay to new server
• File storage: WebDAV in read-only mode
• LMS: Prevent new content creation but allow viewing historical data
• IdP: Keep running but mark as backup

Data Re-Sync Procedure

If a rollback is needed:

1. Email: Re-run imapsync in reverse direction (new → old). Only changed messages need to sync.
2. Files: Run rclone in reverse. Versions created on the new system will be lost.
3. LMS: Restore pre-migration database backup. Any course work done on the new system must be re-exported first.
4. Identity: Restore Keycloak database backup, re-enable old IdP.

The rollback time window shrinks each day. After 7 days, rollback becomes increasingly difficult because of data divergence. After 30 days, a full rollback is no longer practical — at that point, commit fully to the new system.

Communication Plan for Users

Time	Message	Channel
2 weeks before	"Migration announced" — dates, impact, instructions	Email, intranet
48h before	"Final reminder" — what to expect, downtime window	Email
During cutover	"Service status" — real-time updates on progress	Status page
After cutover	"New services available" — login instructions, help links	Email, on-screen banners
Weekly (first month)	"How is it going?" — feedback collection	Survey

Post-Migration Verification

Service-by-Service Checklist

Service	Verified By	Date	Status
Keycloak authentication	Login test by 5 users across groups		✅ / ❌
Email (IMAP/SMTP)	Send/receive test, webmail login
Email (calendar)	Create/modify/delete appointment
File storage (WebDAV)	Upload/download/delete file
File storage (shares)	Verify 3 shared folders
LMS (course view)	Access 5 courses with different roles
LMS (gradebook)	Compare grade export from old to new
BigBlueButton	Create room, share screen, view recording
Jitsi	Create room, test audio/video
Collabora/Office	Open a document, edit, save
Etherpad/CryptPad	Create pad, share, edit collaboratively

User Acceptance Testing

Recruit a group of 20–50 users representing different roles (student, lecturer, administrator, researcher). Give them a test script covering the most common workflows:

1. Log in (single sign-on)
2. Send an email with attachment
3. Schedule a meeting with calendar invite
4. Upload and share a file
5. Access an LMS course and submit an assignment
6. Join a video conference with screen sharing
7. Open a collaborative document

Collect feedback via a structured survey. The migration is not complete until the UAT group approves.

Performance Baseline Comparison

Measure and compare key performance metrics before and after migration:

Metric	Old System	New System	Acceptable
Email delivery time (internal)	< 5 sec	< 3 sec	✅
Email delivery time (external)	< 30 sec	< 15 sec	✅
File upload (10 MB)	2.1 sec	0.8 sec	✅
LMS page load	1.4 sec	0.9 sec	✅
Video conference join time	8 sec	4 sec	✅
Authentication response	1.2 sec	0.6 sec	✅

Old Infrastructure Decommissioning Timeline

Phase	Action	Timeline
1	Power off non-essential legacy services	1 week after cutover
2	Remove DNS records pointing to old infra	2 weeks after cutover
3	Stop legacy file storage (read-only → offline)	2 weeks after cutover
4	Decommission legacy IdP	4 weeks after cutover
5	Stop legacy mail server	4 weeks after cutover
6	Final backup and shutdown legacy infrastructure	6 weeks after cutover
7	Release/repurpose hardware	8 weeks after cutover

Appendix: Quick Reference

Essential Tools

Tool	Purpose	Install
imapsync	Mailbox migration	apt install imapsync
rclone	File storage migration	apt install rclone
vdirsyncer	CalDAV/CardDAV sync	pip install vdirsyncer
kcadm.sh	Keycloak admin CLI	Included with Keycloak
occ	Nextcloud command line	Included with Nextcloud
dig	DNS propagation check	apt install bind9-dnsutils

Key Contacts

• openDesk Edu support: support@openedesk-edu.org
• DFN-AAI federation support: aai@dfn.de
• Community forum: community.openedesk-edu.org

---

Last updated: 2026-06-13. This guide applies to openDesk Edu version 2.x and above.