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.
That fear is fair. AutoSys, originally from CA Technologies and now owned by Broadcom, has run critical work in banks, telecoms and insurance companies for a long time. But it was designed before APIs, containers and cloud setups became normal. Writing and maintaining JIL scripts takes practice, so new team members are slow to get comfortable. And plugging AutoSys into a modern stack, with real-time APIs or event-driven workflows, usually means workarounds.
So the question isn't really "should we move?" It's "how do we move without breaking things?" The answer most teams land on is the same: go slowly, and go one job at a time.
A calmer way to migrate
List your jobs first. Before you build anything, write down what each job runs, when it runs, and what it depends on. Sort them by how many other jobs rely on them. Jobs that stand alone are your easy wins. Jobs with long chains behind them need more care.
Start small. Pick one low-risk job with a clear result, like a nightly report, and rebuild it in the new system first. If something goes wrong, nobody's morning is ruined, and you learn how the new setup behaves before the stakes get higher.
Run old and new side by side. Let both versions run for a while and compare what they produce. This is where you catch the surprises, like a job that depends on something nobody mentioned.
Move dependent jobs together. If job B waits for job A, move them as a pair. Splitting a chain across two schedulers is how you end up with jobs that fire at the wrong time and nobody can say why.
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.
The part nobody writes down
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.
Those habits don't show up in any export. The best way to find them is to talk to the people who get paged when a job breaks, not just the people who built it. Ask them what they check first on a bad morning. Their answers usually point straight at the behavior you need to carry over.
How long does it take?
It depends on how many jobs you have and how tangled their dependencies are. Unmeshed suggests a phased approach like this one and says most organizations complete the move in about 6 to 12 weeks. Treat that as a rough guide, not a promise.
If you're weighing a move, Unmeshed runs scheduled jobs with Bash and Python steps and keeps every run visible from start to finish, so you can see what each job did while you compare old and new.
Top comments (0)