Data Conversion Utilities

When a customer moves to DevStride from another tool, a data-conversion utility imports their existing work: projects, items, time and comments. A utility lives in the private DevStride repository under data-conversion/, with the mappings and decisions that shaped the conversion, so the import can be repeated and audited.

Working material is always encrypted

Some conversions need their source exports and evidence kept for later reruns or audits. That material is only ever kept encrypted:

• One authenticated archive per conversion. The files are packed into a single archive and encrypted with AES-256-GCM. A metadata file beside the archive records the checksums, the nonce and the authentication tag, and names where the key lives, but it never contains the key.
• The key lives in the production secret store, never in the repository or on a laptop. Only engineers with production access can decrypt, and that is deliberate for customer data.

What a development machine needs

• Node.js and the AWS CLI.
• An AWS profile that reaches the production account, with a current sign-in. Profile names differ from machine to machine. The restore script finds the right profile itself, so you don't need to know yours.

No key file, shared password or copy step is involved.

Restoring an archive

Each conversion's archive/ directory has a restore.mjs script and a README with the exact command. In outline:

aws sso login --profile <your-production-profile>   # only if your session has expired
mkdir -m 700 ~/conversion-restore                   # private, outside every git checkout
node data-conversion/<conversion>/archive/restore.mjs ~/conversion-restore/archive.tar.gz
tar -xzf ~/conversion-restore/archive.tar.gz -C ~/conversion-restore

Before writing anything, the script:

• checks every archive part against its recorded checksum;
• confirms the AWS profile really belongs to the production account;
• decrypts and authenticates the whole archive, so tampering is rejected even if the checksums were rewritten;
• verifies the checksum of the decrypted result.

It writes a file only you can read. It refuses to overwrite an existing file or to write inside a git checkout, and it never runs an import.

Handling rules

• Restore only when you need to, keep restored files private, and delete them when you are done.
• Never commit restored or decrypted files, and never paste their contents into tickets, chats or AI tools.
• Never delete, overwrite or rotate an archive's key without first re-encrypting the archive and testing a restore. Without the key, the archive can't be recovered.
• Restoring never authorizes an import. Every import still starts from a fresh preview.