Code Migration: Export ≠ Secure

When you’re migrating code from legacy systems to GitHub, the export looks simple: pull the repo locally with full commit history, do a quick check, push to GitHub. But most teams skip the most important step: scanning for secrets that have been sitting in git history for years. Some of the repos I’m working with are 35 years old. Decades of commits, configuration changes, and forgotten secrets.

I’m working through a lot of repos from different teams right now. The first thing we do is export the source code locally with the full commit history intact. Then we run secret scanning tools like GitLeaks or Trufflehog against the entire repo history. This is the step that catches what you don’t know is there.

What secret scanning actually finds

GitLeaks and Trufflehog are secret scanning tools. They dig through your entire commit history looking for secrets: database credentials, API keys, certificates, private encryption keys. Things that got hardcoded years ago and forgotten. Things that were “fixed” by overwriting them (which doesn’t remove them from history). Things that were copy-pasted into comments and left behind.

GitLeaks recognizes common secret patterns like connection strings and tokens. Trufflehog looks for random looking strings that could be credentials. Together they catch most of what’s hiding in your repo history.

But the tools aren’t perfect. They flag false positives constantly. Random base64 strings. UUIDs. Test data that happens to look like credentials. That’s why you have to review findings manually and separate real secrets from noise.

Once you identify the real secrets, they need to be regenerated in whatever system they came from so the old exposed ones no longer work. Then you variabilize the new ones. Database credentials go into Vault or Azure Key Vault. Pipeline secrets go into GitHub Secrets.

Vault vs GitHub Secrets

GitHub Secrets work great for CI/CD pipeline values. Quick to set up, easy to inject into workflows. But for longer-lived infrastructure secrets, especially ones shared across multiple services, I’d use Vault or Azure Key Vault instead. Better control, easier rotation, central management. In a migration, shared credentials are safer in a vault. Pipeline-specific values can live in GitHub Secrets.

After secrets are handled

Once the repo is clean of secrets, the next step is handling large files. Git gets slow with large binaries, so we migrate those to Git LFS to prevent repo bloat. Then we validate the entire repository structure and push the cleaned export to GitHub.

The moment it’s in GitHub, it’s permanent. That’s why the local scanning step matters so much.

The real problem

Most teams skip this. They export, do a quick manual look, assume private repos are fine, and push. But private repos aren’t that private. Access controls change. People leave companies. And once a secret is in git history, it’s there forever.

We spent roughly 40 hours scanning, reviewing, and scrubbing 150 services. That’s time most teams don’t invest. But that investment prevented what could’ve been weeks of incident response if any of those secrets had been compromised later.

Don’t move the problem from your legacy system to GitHub. Scan it first. Clean it locally. Then push.

That’s the migration nobody talks about but everyone should be doing.