Moving Your X Archive to a New Device Without Losing Data

When people move to a new laptop or phone, the X archive usually sits at the bottom of the list. It is one ZIP file, you copy it across, it opens, and the job looks done. The value of an archive is not in the file. It is in the judgment you accumulated on the old machine: the whitelist of tweets that must stay, the exclusion list of false positives you already cleared, and the check baseline that recorded last time's score and risk counts. None of that lives inside the ZIP.

This piece splits a X archive migration into three stages: before the move, during the move, and after. Work through them in order and the check on the new device should line up with the old baseline instead of reshuffling it.

Lock down three things on the old device first

Do not pull the drive yet, and do not start cloud sync yet. The old device still holds the full context, and this is the cheapest moment to capture it.

1. The original archive ZIP. Do not keep only the extracted folder. The package contains tweets.js, like.js, direct-messages.js and other files, and some parsers depend on the original directory layout. A missing file triggers an error rather than a silent skip.
2. The last check baseline. Score, total risk item count, and the breakdown by category. Compare against it after the move and you can tell immediately whether data is missing or the parser version differs.
3. The whitelist and exclusion list. These are the expensive part. The whitelist holds tweets that must stay. The exclusion list holds items you already reviewed and cleared. Both are products of human judgment, and rebuilding either one takes hours.

If the old device still boots, put those three items in a folder of their own and keep them separate from the archive ZIP. Mix them into the same folder and the move will very likely carry the package over while the configuration stays behind.

Where the archive actually sits

X hands you a single compressed package, and the extraction location is your choice, so there is no standard path. These are the usual landing spots, useful for locating the file on the old device quickly.

System	Typical location	Size reference
Windows	Downloads folder, or a folder you created during extraction, with a data subfolder inside	50MB to 400MB
macOS	Extracted into Downloads, with the data subfolder one level down	Same range
Android	Download folder in internal storage	Usually smaller, incomplete media
iOS	Downloaded item in the Files app, needs manual extraction	Same as Android

The size gap comes from media files. The same account downloaded on a desktop produces a larger package than on a phone, because mobile exports often omit original image and video files. Moving from a phone to a computer, confirm the package you are carrying came from a desktop download, or the check will come up short on image tweets. The mobile route is covered in downloading an X archive on your phone.

The three pieces of configuration that travel with the data

Plain text or a spreadsheet is enough. What matters is that you fix them in a file instead of keeping them in your head.

• Whitelist format. One tweet link or ID per line, with a short reason after it. The reason column looks redundant until three months later, when it is the only thing that explains the call you made.
• Exclusion list format. ID, reason, plus a column for the false positive type, such as coordinate numbers, domain jargon, or quoted material. Once one type stacks up, you can tune the parser against it.
• Baseline snapshot. Date, total score, and the per-band item counts. A single score number is not enough, because categories carry different weights and a flat score can hide a shifted structure. The weighting logic is in how footprint score weights work.

If the old device is already gone, you have to rebuild from the archive. Run the check first to produce a fresh baseline, then add back the whitelist entries you remember. Reversing that order wastes a full pass, since you end up doing the manual judgment twice.

Six steps for the move

1. Verify the package. Compare the file size against the old device, then confirm tweets.js is visible after extraction. If you only kept the extracted folder, validate against the original package first.
2. Copy the ZIP, not the extracted folder. The extracted folder holds thousands of files, and cross-system copying invites case or encoding mismatches. A single ZIP carries far less risk.
3. Extract into a dedicated folder on the new device. Do not drop it into Downloads. A second download later will mix the two, and you will lose track of which is which.
4. Import the exclusion list, then the whitelist. When the two overlap, landing the exclusion list first keeps whitelist entries from being re-flagged.
5. Run one full parse. Its purpose is to establish the new baseline, so resist deleting anything while you are at it. Clean up on the first run and you cannot tell a data problem from an operation problem later.
6. Compare against the old baseline. Score and per-band counts should land close. A gap wider than about ten percent means stop and investigate, usually a different package version or an incomplete exclusion list.

Where the package lives matters too. Keeping it inside a synced folder means the tweet text gets replicated to another device anyway. Safer storage is covered in storing an X archive safely.

How to verify the move

Check data completeness and judgment completeness separately. The two have different failure paths, and mixing them into one pass sends you back and forth.

Check	Pass condition	Look here first if it fails
Package integrity	File size matches the old device, tweets.js present	Interrupted copy, or the extracted folder was moved by mistake
Parsed entry count	Matches the old baseline tweet total	Package came from a mobile download
Risk item count	Per-band counts close to the old baseline	Exclusion list imported incompletely
Whitelist active	Whitelisted tweets stay out of the cleanup queue	ID formatting altered by an editor
Old device data	Left in place until verification passes	Nothing to check

The last row gets skipped often. Keep the archive and configuration on the old device until the new one passes. Two copies cost very little, while requesting a fresh archive and rebuilding the judgment costs a great deal. For the report side, compare structure against what a footprint report contains.

When to skip migration and download fresh

Migration fits the case where the archive is still available and the configuration is worth keeping. These cases are simpler if you start over.

• The old device is sold or given away. There is no source to move, so a new archive request is the only route.
• The package is two years old. Recent tweets are not in it, so you would request again anyway. One fresh download beats a move plus a request.
• The whitelist and exclusion list were never saved. Nothing carries over, leaving only a file copy, which is barely different from downloading again.
• You switched phone platforms. Android and iOS expose different export routes and differ in media completeness, so a clean request on the new platform is tidier.

A fresh export takes a few days to arrive. Keep the old archive until the new one lands and passes verification. Both paths benefit from the checks in fixing a failed archive download, which covers the points where either route tends to stall.

A migration deletes nothing. Its payoff is the hours of judgment you do not have to rebuild. Once the new device is set up, run the check to confirm the parse matches the old baseline. The check at digital-footprint-health.shop is free from the homepage, parses your archive on your own machine, and never uploads tweet text. Cleanup scope and cost are on the pricing page, and the method write-ups sit in the blog index.