Before you touch the file
Copy the file first and work on the copy. This sounds like the kind of advice nobody follows, so make it concrete: open the sheet, duplicate it, rename the duplicate with the date, and leave the original closed for the rest of the session. Every step after this one can be undone only if a clean version exists somewhere that nothing has written to. It takes ten seconds and it is the difference between a bad afternoon and a lost sheet.
Then write down what the sheet is made of. Column order, header names, which column holds the wrapped address, which holds the product number, and which holds anything you typed yourself by hand. Handwritten columns are the ones that vanish silently during a move, because a remapping routine only knows about the columns it was told to expect. A one-line inventory on paper beats a memory of how the sheet used to look back in March.
Decide what the move is for before choosing where to go. Twenty-two platform objects are tracked here, eleven of them with a directory page, and the differences that matter are narrow and checkable: whether the destination still accepts rebuilt source addresses, whether free inspection photos have been confirmed, and the date of the last check. Rates and storage terms are marked unverified on this site for every platform, including the ones that look obvious. Unverified is a status, not a shrug.
Set a stopping rule that has nothing to do with how the move feels. A workable one: if two rows in ten come back unusable after the first paste, stop and go back to the copy rather than repairing in place. Repairing in place is how a sheet acquires four generations of corrections and no way to tell which generation a row belongs to. Write the rule down before you need it, because you will not be in the mood to invent one at row three hundred.
While the columns are being remapped
Mapping columns is the part people rush and later blame on the destination. The sheet column mapper exists for this single step: it takes the header row of your sheet and the header row the destination expects, and it reports which columns line up, which have no partner and which would collide if you pasted as-is. Read that report before pasting anything, and treat an empty partner as a decision rather than as an error. Some columns deserve to be dropped, and some deserve to be carried across by hand.
Addresses are the columns that never map cleanly. A wrapped address from a closed platform has no equivalent field at the destination, so it usually lands in a notes column or gets dropped. Put it in notes. The rebuilt source address is the one that travels, and it travels because it points at the source host rather than at the platform that wrapped it. That is also why a rebuild has to happen before the move and not after it: you cannot rebuild what you already deleted.
Numbers deserve a second look on the way across. Product numbers, order numbers and dates all look like plain text and all behave differently once a destination decides a column is numeric. Long numbers can lose their tail, leading zeros can disappear, and a date written as text can be read as something else entirely. Compare the first ten rows and the last ten rows before you trust the whole column. Ends first, because damage at a column boundary shows up there before it shows up in the middle.
Keep a row count running through the whole step. Note the number of rows before the map, after the map, and after the paste. Three counts that agree are the cheapest proof that nothing was silently dropped, and a count that disagrees tells you to stop at that moment rather than at the end of the session, when the source of the loss is anybody’s guess. Two numbers and a short note are enough; a formal log is not required.
After the first paste into the new agent
Paste a small block first, not the whole sheet. Ten rows is enough to expose a column that mapped wrongly, a number that lost its tail, or an address field that arrived empty. The first paste is a test, so keep the rest of the data out of the destination until the test has been read. If the destination lets you clear an import, clear it and start again rather than editing what landed. Editing inside a fresh import hides the mistake instead of fixing it.
Then open three of the pasted rows by hand and compare them against the copy, field by field. Choose rows that are awkward rather than typical: one with a long number, one with a note you wrote yourself, one whose address was rebuilt from a wrapper. Easy rows agree in any version of the sheet, which is exactly why they prove nothing. Pick the rows you would least like to debug later and debug those first.
Expect the destination to have opinions. Every platform object on the platform ledger is described with the same fields, and most of those fields come back not verified, including the ones people ask about most: rates, how long something can sit in storage, and which payment methods are accepted. Where a platform publishes a description of itself, this site treats that as a description and not as a confirmed number. That habit is dull, and it is the only reason the ledger is worth reading at all.
Give the moved sheet a new name and a new first row. A one-line header that records the date of the move and the destination turns the file into something you can date later. Sheets that carry their own provenance survive reorganisation, laptop changes and the moment when somebody else inherits the folder and has to guess what they are looking at. A date in row one costs nothing and answers the first question anybody asks about an old sheet.
Putting it back if it goes wrong
Most bad moves are reversible for about an hour and painful afterwards. The copy you made before starting is the thing that makes the hour possible, so the first recovery step is not diagnosis, it is reopening the copy and confirming it still has every row. Only then is it worth asking what went wrong, and by that point you are asking about a copy rather than about your only sheet. Recovery and curiosity are two separate jobs, and they fight when done at the same time.
If the destination has already accepted the data, undo there before you fix anything here. Remove the imported block, or mark it clearly as abandoned if removal is not offered. Two live versions of the same sheet, one of them wrong, is a worse position than one wrong version, because the next person cannot tell which one to trust and will probably merge them. A merged sheet is the one outcome nobody can unpick later.
Then narrow the failure to a single column before touching any row. Columns fail in families: every date, every long number, every address. If the damage is scattered across unrelated columns instead, the cause is usually the paste itself rather than the mapping, and the fix is to redo the paste in smaller blocks until one block comes through clean. One clean block tells you more about the cause than a whole sheet of symptoms. Halving the block size is a cheap experiment and it usually settles the question in two attempts.
Whatever happened, write it down on the sheet you keep. A single line naming the date, the destination and what went wrong saves the next attempt from repeating it, and it converts a bad afternoon into a record. The open questions page exists for the parts nobody has settled yet; the parts you have settled deserve the same treatment in your own file. Nobody inherits your memory. They inherit the file, and the file is what has to carry the warning when somebody opens it cold in six months.