How would you plan a migration in an environment nobody fully understands?

Start with an inventory, not a redesign. Record what runs where, who owns it, how it gets deployed, what it depends on, and whether anyone still uses it. Include the awkward undocumented jobs and the quiet systems that have no alerts. A basic dependency map is more useful than a polished target architecture built on guesses.

Then mark the things with a near-term deadline or a clear operational risk. That gives you a reasoned first slice instead of trying to fix every problem at once.

Draw it out. A rough diagram of the current setup, including the application paths and deployment flow, makes missing knowledge visible. Keep that separate from a second diagram of the proposed design. Share both with whoever owns the systems and get corrections before treating the new diagram as a plan.

It does not need to be a special tool. A whiteboard or a simple diagram editor is fine. The useful part is making assumptions easy to inspect.

Be careful not to confuse a pipeline migration with a safer infrastructure design. If a job deletes and rebuilds resources, first figure out exactly what it touches, what state it relies on, and how you would recover from a bad run. Moving the same script to a different runner does not reduce its blast radius.

I’d migrate a small, low-risk workflow first, document the behavior, and add checks and clear approval points before attempting anything that can take down shared services.

Don’t move something to Kubernetes just because Kubernetes is the destination for another project. Check the actual requirements, support burden, dependencies, and recovery plan for each workload. Some existing deployments may be perfectly adequate while you focus on systems that are exposed, unsupported, or close to a deadline.

Preserve what works until you understand what it does. “Old” and “unsafe” are not automatically the same thing.

Pick one narrow improvement and make it a solid example: a documented deployment path, repeatable infrastructure changes, basic monitoring, and a rollback plan. Show the people involved what improved, then use that pattern for the next system.

That tends to build more trust than proposing a giant rewrite while everyone is still learning what the current setup does.