How to Move a Visual SourceSafe Project to Another Database Without Losing History

Moving projects between Visual SourceSafe (VSS) databases without losing version history is possible when you use VSS archive and restore workflows correctly. This guide is for VSS administrators who need a safe, repeatable migration path and want clear steps for both GUI and command-line methods.

Originally published on 2009-10-06; fully revised and updated.

What this procedure solves

Use this approach when you need to move one or more VSS projects to another database and keep their history intact.

• Copy a VSS project from one database to another without losing history
• Move VSS projects to a new server or location
• Transfer projects across databases while preserving change history
• Perform a migration with either interactive or scriptable tooling

Applies to, prerequisites, and constraints

According to the original guidance, this process applies to Microsoft Visual SourceSafe 5.0 Standard Edition and Microsoft Visual SourceSafe 6.0 Standard Edition, and requires VSS 5.0 or later.

• Use SSARC and SSRESTOR (included with VSS) if you want command-line control.
• You need SourceSafe Admin privileges.
• For cross-database restore, the archive must include the latest versions of files in the project.
• After restore, physical file renaming may require reconnecting or rebinding tools integrated with VSS.
• Before archive/restore, ensure no one is using the database and that maintenance jobs (such as ANALYZE) are not running during the operation.

Choose a migration method

Archive and restore workflow

flowchart TD
    A[Plan migration window] --> B[Confirm admin access]
    B --> C[Ensure no active users]
    C --> D[Archive source project]
    D --> E[Copy SSA archive file]
    E --> F[Open target database]
    F --> G[Restore project]
    G --> H[Validate history and labels]
    H --> I[Reconnect integrated projects]
    I --> J[Take fresh backup]

Method 1: Use Visual SourceSafe Administrator

Archive from the source database

• Ensure no users are connected, and pause operations such as ANALYZE during the archive.
• Open the source database in Visual SourceSafe Administrator.
• Go to the Archive menu and select Archive Projects.
• Select the project(s) to archive.
• Choose archive options and output file location.
• Set version scope for archived data.
• Add a comment describing the archive.
• Finish the wizard to generate the .ssa archive file.

Restore into the target database

• Ensure no users are connected to the target database, and pause ANALYZE during restore.
• In Visual SourceSafe Administrator, open the target database.
• Go to the Archive menu and select Restore Projects.
• Select the archive file to restore from.
• Choose which items to restore.
• Set restore options and destination as needed.
• Add a comment documenting the restore.
• Finish, then verify that restored items are in the intended location.

Method 2: Use SSARC and SSRESTOR from the command line

The following examples are preserved from the original guidance and are useful as templates. Validate switch behavior in your VSS version before running in production.

SSARC examples

SSARC -d- -yadmin,password archive.ssa $/
SSARC -d- "-vlProduction Release" -yadmin,password -olog.txt archive.ssa $/Test
SSARC -d -x -yadmin,password archive.ssa "$/Project Global Domination" $/OtherProject
SSARC -i -yadmin,password -olog.txt "-cArchive Everything" archive.ssa $/Code language: JavaScript (javascript)

• Archive the full database while leaving database contents unchanged.
• Archive project data since a label and write a log file.
• Archive multiple projects with deletion-related options from the original example set.
• Run non-interactively with logging and an archive comment (useful for scheduled tasks).

SSRESTOR examples

SSRESTOR -la -yadmin,password archive.ssa $/
SSRESTOR "-p$/Test 2" -sD:\newfolder\ -yadmin,password backup.ssa $/TestCode language: JavaScript (javascript)

• List archived contents before restoring.
• Restore a project from an archive to a different project path/location in another database context.

Post-restore validation checklist

• Confirm project tree and folder structure in the target database.
• Open file history for multiple files and verify expected revisions.
• Verify labels and comments that should have been preserved.
• Check for duplicate-name conflicts or skipped items.
• Reconnect external integrations that depended on old physical file mappings.
• Create a fresh backup of the target database after successful validation.

Common pitfalls and best practices

• Back up before every archive or restore, and keep copies in multiple locations.
• Test restore procedures on a non-production database before touching live data.
• Avoid permanent deletes unless you have verified restoreability.
• Do not run migrations while users are active in the same database.
• Protect credentials; avoid exposing admin passwords in shared scripts or logs.
• Document archive comments and logs so changes are auditable later.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.