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:
- 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.
- Bulk import: Use
ldapsearchto 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:
- Export users from the legacy directory to LDIF
- Use Keycloak's
Import Usersfeature via the Admin Console or thekcadm.shscript - Set temporary passwords or force password change on first login
- 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:
- Users authenticate against the existing university IdP
- The IdP sends a SAML assertion to Keycloak
- Keycloak maps the assertion attributes to its internal user model
- 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:
- Deploy a Keycloak instance (or use the one included in openDesk Edu)
- Configure federation to your test IdP or LDAP directory
- Create a test service (e.g., a test Nextcloud instance) configured to use Keycloak OIDC
- Have a small group of IT staff test login, logout, session refresh, and MFA
- 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:
- Run a preliminary sync to move old data, then an incremental sync for recent changes
- Use
--split1to split large folders into ranges of messages - Increase timeout values with
--timeout1and--timeout2 - 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:
- Login test: Can the user log in via IMAP and webmail?
- Folder count: Does the folder hierarchy match the source?
- Message count: Compare total message count (use
SELECT INBOXIMAP command) - Recent send/receive: Can the user send and receive new messages?
- Calendar: Are future appointments present?
- 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:
- Mount the legacy storage (NFS, SMB, or local disk)
- Copy data to the openDesk Edu storage backend (e.g., Longhorn volume, NFS export, or S3 bucket)
- 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:
- Migrate everything (recommended): Includes version history and trashed files. Use
rclonewith--include "*/versions/*"and--include "*/trash/*". - Start fresh: Only migrate current files. Users lose version history but migration is faster.
- 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:
- Document all existing LTI 1.3 platform deployments and tool registrations
- Generate new platform keys in the new ILIAS/Moodle instance
- Re-register tool deployments with new platform IDs and public keysets
- 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 settingsprosody.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
- T-48h: Lower TTL on all affected records to 300 seconds
- T-24h: Announce cutover window to all users
- T-0h (Auth cutover): Change Auth/CNAME records to point to openDesk Edu Keycloak
- T+1h (Mail cutover): Change MX records
- T+2h (File cutover): Change
cloudCNAME - T+3h (LMS cutover): Change
lmsCNAME - T+4h (Conferencing cutover): Change
meetCNAME - 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:
- openDesk Certificates (Bundesdruckerei): For German universities requiring qualified certificates
- 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:
- Email: Re-run imapsync in reverse direction (new → old). Only changed messages need to sync.
- Files: Run
rclonein reverse. Versions created on the new system will be lost. - LMS: Restore pre-migration database backup. Any course work done on the new system must be re-exported first.
- 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 | |
| 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:
- Log in (single sign-on)
- Send an email with attachment
- Schedule a meeting with calendar invite
- Upload and share a file
- Access an LMS course and submit an assignment
- Join a video conference with screen sharing
- 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.
