How to Handle Locked Files During a Windows Server Migration

File server migrations often happen while employees are still working. Documents remain open, databases may hold files continuously, and background applications can write to shared locations throughout the day. Locked or changing files can therefore be skipped, copied inconsistently, or generate errors during transfer. The challenge is deciding which files can safely move while users remain active and which require a controlled outage.

Understand Why a File Is Locked

A file may be locked because a user has it open in an application, a service is writing to it, antivirus is scanning it, or a business application maintains an exclusive handle.

The response depends on the source. A Word document opened by one user is different from a database file actively used by an application.

Use an Initial Copy While Users Work

Large file migrations often benefit from copying most data before the outage window. During this stage, some open or changing files may fail or may need to be recopied later.

The objective is to move the bulk of stable data early so that only changed and previously unavailable files remain for final synchronization.

Review Transfer Logs

A file server migration tool or copy utility should produce enough logging to identify files that failed, were skipped, or changed during transfer.

Do not treat a completed progress bar as proof that every source file reached the destination.

Categorize Locked Files

Review failures and determine whether they are ordinary user documents, application files, temporary files, databases, or system data.

Some temporary files do not need migration at all. Others may represent critical application state and require a specific migration process rather than ordinary file copying.

Communicate a Final Read Only or Outage Window

Eventually the team needs a period where users stop modifying the source. Ask employees to close documents and applications before final synchronization.

For critical file servers, administrators may temporarily prevent user access or remove shares so that no new writes occur while the last transfer completes.

Stop Dependent Services Carefully

If services keep files locked, identify whether they can be stopped during the outage. Document service names, dependencies, and startup procedures.

Never terminate processes randomly simply to release a file. The service owner should understand the effect and how the application will recover.

Databases Require Database Aware Migration

Database files should not generally be treated as ordinary documents while the database engine is actively writing to them. Use appropriate database backup, replication, detach, export, or application specific migration methods.

A file server may contain application data that requires coordination with application teams.

Recopy Failed Files After Locks Are Released

Once users and relevant services are stopped, rerun the transfer for skipped or changed files. The final synchronization should be significantly smaller than the original copy if earlier stages were successful.

Review logs again before cutover.

Compare File Counts and Sizes

File count and total data size provide useful high level checks, but they are not sufficient by themselves. A dataset can contain the same number of files while one critical document remains outdated.

For important shares, validate timestamps, hashes, or other checks according to migration risk.

Do Not Ignore Long Running Sessions

Users may maintain SMB connections even after they believe applications are closed. Administrators can review open files and sessions on the source before final synchronization.

Disconnecting users should be done during an agreed outage window because unsaved work can be lost.

Plan Around Files That Cannot Move

Some locked files may belong to software that cannot be stopped within the available migration window. In that situation, the project may need a different migration method or a separate application cutover.

A server migrations plan should recognize these dependencies before migration night rather than discovering them during the final transfer.

Keep Users Away Until Validation Is Complete

After the final copy, avoid reopening the source and destination simultaneously for normal work. Allowing users to modify both locations creates divergent versions that are difficult to reconcile.

Complete destination validation first, then release the new server as the active service.

Make Locked Files a Managed Exception, Not a Migration Surprise

Locked files are normal on active file servers. They become dangerous only when the migration plan assumes every file will copy cleanly while the business continues working.

A staged transfer, clear outage window, service coordination, detailed logs, and final synchronization turn locked files into a manageable part of the process. By identifying the reason each important file remains open and using the correct method to move it, administrators can protect data consistency without extending downtime unnecessarily.