Five Phases to Move Access to RDP Without Losing Data

Your team keeps the same Access forms, reports, and VBA logic — but opens them from home, a second office, or a client site without copying files or fighting VPN latency. That is the practical outcome of hosting Access on a remote Windows server and connecting through RDP. The risk is not the destination; it is the cutover. A rushed file copy, an outdated linked-table path, or a go-live before finance signs off on totals can erase trust faster than any server outage. This checklist is built around five phases that protect production data while you move.

Treat the migration as a controlled relocation, not a weekend experiment. Each phase has a clear exit criterion: you do not advance until the previous gate passes. That discipline is what separates a smooth RDP rollout from a support ticket spiral.

Phase 1: Freeze and snapshot

Before anything touches a cloud folder, stop the drift. Announce a short change window where schema edits, new linked tables, and ad hoc file moves pause. You are not shutting the business down — you are creating a known-good baseline.

Capture what production actually runs today

• Verified full copy

  Take a complete copy of the front-end and back-end files after the last user closes for the day. Open the copy on a workstation — not the live file — and confirm forms, reports, and key queries run without error.

• Dependency map

  List linked tables, ODBC sources, Excel imports, PDF export folders, and any VBA references to drive letters or UNC paths. Missing one path is the most common post-migration failure we see.

• Concurrency snapshot

  Note peak concurrent users and the heaviest workflows (month-end posting, inventory counts, billing runs). You will size the host and pilot group against this reality, not against average Tuesday traffic.

• Rollback anchor

  Store the snapshot off the production share with a dated name. If cutover day goes sideways, you revert to this file set — not to whatever was edited mid-migration.

Phase 2: Host prep

The server is the new home for your Access runtime, Office components, and shared data folders. Under-provisioning shows up as slow form loads; misconfigured permissions show up as “could not use file already in use” errors at 4:45 p.m. on Friday.

Build the environment before the database arrives

• Right-sized Windows host

  Provision a dedicated Windows Server VM with enough RAM for Access, report rendering, and concurrent sessions. Disk I/O matters when five users compact or run large exports at once.

• Runtime stack

  Install the same Access/Office bitness your app expects, plus ODBC drivers for any external databases. Match versions to what you tested locally — “close enough” breaks DAO and reference libraries.

• Shared folder layout

  Create a consistent path structure on the server (for example, D:\AppData\FE and D:\AppData\BE). Every user and every relink will point here; avoid user-specific Desktop paths.

• Access and backup policy

  Enable RDP for named users only, restrict admin rights, and schedule automated volume snapshots or file copies before you load production data. Backups that start after go-live are too late.

Phase 3: File move and relink

Copying the .accdb is the easy part. Making every connection string, shortcut, and macro path resolve on the server is where projects stall. Do this work on the snapshot first; promote to production paths only after a clean server-side test.

Promote files, then prove every link

• Transfer with checksums

  Upload front-end, back-end, and supporting folders via secure transfer. Compare file sizes and modified dates; for critical backends, verify hash if your tooling supports it.

• Relink linked tables

  Use the Linked Table Manager (or scripted relink) so every backend points to the server share — not the old S: drive. Run this logged in as a standard user account, not only as admin.

• Repair VBA and external paths

  Search modules for hard-coded paths, Shell commands, and FileDialog targets. Update export directories, template folders, and integration drop zones to server locations.

• Split-database hygiene

  If you are not already split, consider separating FE and BE before multi-user RDP load. Deploy a single front-end shortcut per user that opens the shared back-end on the server.

Phase 4: Pilot users

Do not invite the whole company on day one. A pilot of two to five people who represent real workflows — order entry, AP, inventory, management reports — surfaces path and permission gaps before they become company-wide blockers.

Run real work on the server for a full business cycle

• Representative accounts

  Give pilot users standard (non-admin) Windows logins and RDP files with the server address pre-filled. They should follow the same steps they use locally.

• Parallel totals check

  For finance and operations, reconcile control reports against the legacy environment for at least one close cycle or billing run. Discrepancies now are cheaper than disputes after cutover.

• Concurrent session test

  Have pilots perform overlapping edits on the same tables and forms you expect at peak. Watch for locking conflicts and long-running queries.

• Issue log with owners

  Track every error message verbatim, the form or report involved, and who fixes it. Close the log before production cutover — open items become production defects.

Phase 5: Production cutover

Cutover is a calendar event with a rollback decision point, not a vague “we’re live now.” When the pilot sign-off is documented, block new entries on the old environment, take a final incremental export if needed, and point all users to RDP.

Go live with a defined window and exit criteria

• Final sync and read-only legacy

  After the last approved transaction on the old system, set the legacy database read-only or take it offline. Ambiguous dual-live periods cause duplicate orders and reconciling nightmares.

• User communication

  Send connection instructions, support contact, and what to do if RDP fails (who to call, not “try again later”). Include Mac or tablet users if they connect via alternate clients.

• Hypercare week

  Staff extra coverage for the first five business days. Monitor event logs, failed logins, and slow reports. Fix path and permission issues immediately — habits form fast.

• Post-cutover backup proof

  Confirm automated backups ran on schedule and rehearse a restore to a sandbox folder within the first two weeks. A backup you have never restored is only hope.

Mistakes that cost more than the migration

Skipping the freeze phase and copying a file mid-edit. Relinking only as admin while users hit broken links under their own accounts. Going live before pilots reconcile totals. Treating RDP as “set and forget” without patch and backup ownership. Each is avoidable when phases gate the next step.

If you want the same Access application your team already trusts — reachable from anywhere without rebuilding forms — see our Access database cloud hosting service. We plan the freeze window, build the host, relink dependencies, run pilot validation, and stay through cutover.

When this work needs production scope, see our MS Access cloud hosting service and the Custom Business Systems solution hub for related outcomes.

When to handle this in-house

Follow snapshot → host prep → relink → pilot → go-live with rollback paths documented before moving production paths.

When to involve DabOps

Engage when linked tables, credential stores, or multi-site users make cutover riskier than a weekend allows.

• Inventory every linked path and ODBC DSN before snapshot.

• Pilot with real operators on the hosted session.

• Schedule post-cutover backup verification on the new host.

Book Automation Assessment · MS Access cloud hosting · Custom Business Systems · Case studies