How do I archive an old project so I can revive it years later?

What this is

A repeatable procedure for archiving any project — WordPress, Next.js, static site, FastAPI service, desktop app — into a single zip that can be cold-stored and reopened years later with no tribal knowledge. Optimized for "future you, who has forgotten everything."

When to archive

• Project is paused indefinitely or completed
• Client engagement ends
• Codebase is being moved off active development machines
• Before decommissioning infrastructure (databases, hosting, domains)

Universal archive contents

Item	Required	Notes
Application source code	Yes	Full source tree minus regenerable output
Lock file	Yes	package-lock.json, composer.lock — exact dependency versions
Environment config	Yes	.env, wp-config.php — credentials as-is, note rotation needed
Git history	Yes	.git/ directory
Database export	Yes	pg_dump, mysqldump, .sqlite file — whatever the project uses
Build binder	Yes	All plans and docs/ files
Install guide	Yes	{PROJECT}-INSTALL.md at zip root
Legacy/reference materials	If applicable	Predecessor apps, extracted docs, reference databases
Design assets	If applicable	See Step 3

Never include

• node_modules/, vendor/ (PHP), __pycache__/
• .next/, dist/, build/, .cache/ — anything regenerable
• _backups/ folders (too large, not needed for restore)
• OS junk: .DS_Store, Thumbs.db, desktop.ini

Install guide template

Every {PROJECT}-INSTALL.md must cover:

1. Archive manifest — what's in each folder/file
2. Prerequisites — runtime versions, services, accounts needed
3. Step-by-step restore — extract → install deps → configure env → restore database → run
4. Environment variable reference — every key, what it does, where to get a new value
5. Key architectural notes — auth provider, ORM, billing, ports, routing
6. Infrastructure notes — hosting, database, services connected
7. Legacy reference — what legacy folders are and why they're included

Written so someone who has never seen the project can get it running.

Step 1 — Inventory

List every location where project files live:

• Working directory (source code)
• Cloud build binder (plans and docs/)
• Database (local MySQL, managed Postgres, etc.)
• Legacy applications or reference material
• Design assets (fonts, PSDs, SVGs, brand files)
• External services with config that matters (auth, payment, email, DNS, hosting)

Step 2 — Export the database

Do this before anything else. The database is the one thing you can't reconstruct.

• WordPress/MySQL: mysqldump
• PostgreSQL: pg_dump --format=custom or pg_dump --format=plain
• SQLite/Access: include the .db / .mdb file directly

Name the export {PROJECT}-db-export-YYYY-MM-DD.sql. Include at zip root.

Step 3 — Handle design assets

Pick one approach per project:

Approach	When to use
Include in zip	Total assets < 200MB. Fonts, favicons, small SVG sets.
Separate asset archive	Assets are 200MB–2GB. Create {PROJECT}-ASSETS-YYYY-MM-DD.zip alongside. Reference it in the install guide.
Reference only	Assets live in cloud permanently. Note the path in the install guide. Don't duplicate.

Never delete original asset files. If in doubt, include them.

Step 4 — Build the zip

# Start with source code
cd /path/to/project
7z a -tzip ARCHIVE.zip . -xr!node_modules -xr!.next -xr!dist -xr!vendor

# Add database export
7z a -tzip ARCHIVE.zip /path/to/db-export.sql

# Add build binder
cd /path/to/cloud/project
7z a -tzip ARCHIVE.zip "plans and docs/"

# Add legacy materials (if any)
7z a -tzip ARCHIVE.zip "legacy-folder/"

# Add install guide last
7z a -tzip ARCHIVE.zip {PROJECT}-INSTALL.md

Step 5 — Write the install guide

Use the template above. Be specific. Include exact commands.

Step 6 — Verify

Checklist:

• Source code present (no node_modules / vendor / build artifacts)
• Database export present and non-empty
• .env / config files included
• .git history included
• Build binder included
• Legacy/reference material included if applicable
• Design assets handled (included, separate zip, or documented)
• Install guide at zip root
• Zip opens and extracts cleanly

Smoke test (strongly recommended): extract to a temp folder, run npm install / composer install / equivalent. Confirm it completes without errors. You don't need to stand up the full database — just verify the code is intact and installable.

Step 7 — Infrastructure teardown

After the archive is verified, decommission what you don't need anymore:

Service	Action	Notes
Database (managed)	Drop the database or destroy the cluster	Only after confirming export is in the zip
Auth provider	Delete or archive the application	Keys in .env will stop working
Billing (Stripe)	Archive the product/prices, cancel webhooks	Don't delete the account if shared
Email (Resend, etc.)	Remove domain or API key
Hosting (Vercel, DO, etc.)	Delete the deployment
Domain/DNS	Let expire or park	Note renewal date in install guide
Local Sites entry	Delete from Local	After zip is verified

Do not tear down anything until Step 6 is fully complete.

Step 8 — Store and back up

1. Move the zip to long-term storage (external drive, cold cloud bucket)
2. Confirm cloud sync of the build binder (it's still in cloud — the zip has a copy, cloud has the originals)
3. Update your archive log

Retention

• Primary storage: external drive or cold cloud bucket
• Secondary: build binder stays in cloud sync permanently (it's lightweight)
• Rule: archives should be backed up to a second location if the project has any chance of being revived
• Retention: indefinite. Don't delete archives. Storage is cheap. Rebuilding is not.