AutoSys Migration, One Job at a Time

Description and use

A phased, job‑by‑job migration from AutoSys to a modern scheduler reduces risk and preserves hidden dependencies.

Problem

Migrating from AutoSys to a modern scheduler risks breaking critical jobs and losing undocumented dependencies.

Outcome

A phased, job‑by‑job migration reduces risk, allows side‑by‑side validation, and preserves hidden dependencies.

Workflow

• List all jobs, their schedules, and dependencies.
• Prioritize jobs by dependency count; start with low‑risk, standalone jobs.
• Rebuild a low‑risk job in the new scheduler. Run both AutoSys and new job concurrently. Compare outputs and logs. Move dependent jobs together as a pair. Retire the AutoSys job after consistent matching runs.
• Repeat until all jobs are migrated.

Evidence

Nobody enjoys a scheduler migration. The old system has been running for years, nobody remembers why half the jobs exist, and everyone is a little scared to touch the ones that work.

Source

List your jobs first. Before you build anything, write down what each job runs, when it runs, and what it depends on.

Source

Start small. Pick one low-risk job with a clear result, like a nightly report, and rebuild it in the new system first.

Source

Run old and new side by side. Let both versions run for a while and compare what they produce.

Source

Move dependent jobs together. If job B waits for job A, move them as a pair.

Source

Switch off the old job last. Only retire the AutoSys version after the new one has matched it cleanly for a good stretch of runs.

Source

The job definitions are the easy part. They're written down, so you can read them. What's harder is everything around them: a script that quietly retries when it fails, a downstream team that expects a file to land before 6 AM, an alert that goes to one person's inbox and nobody else's.

Source

Unmeshed suggests a phased approach like this one and says most organizations complete the move in about 6 to 12 weeks.

Source