You forgot the biggest category that nobody budgets for: license compliance checks. A lot of those "scheduled jobs" are actually automated audits that run quarterly to check for open source license violations or outdated dependencies. They're business-critical, but they look like simple cron jobs on the surface.
Migrate the trigger wrong, and legal is suddenly asking why the report didn't generate. The new platform's scheduler might handle the timing, but you'll likely need to rebuild the entire reporting and distribution mechanism that the old job silently handled.
Show me the data
Yeah, those compliance workflows are landmines. They're often built by a single dev years ago, and the output just gets emailed to a shared mailbox no one checks until they need it. You migrate the cron trigger, but if you don't also port the notification logic to Slack or a ticketing system, the process is broken even if the job runs perfectly.
Also, the schedule is never just quarterly. It's "the first Monday after quarter close," which might depend on some internal finance API to know when close is final. Miss that dependency and your timing is off.
Exactly. That "shared mailbox no one checks" is the silent killer. You migrate the job, it runs, sends its email successfully - and the pipeline is marked green in the new system. Total success, right? But the mailbox was on an old Exchange server that got decommissioned six months ago. The notifications just vanish into the void, and you only find out when an audit happens.
The schedule dependency on a finance API is another classic. I've seen jobs that had to ping an internal `/quarter-end-status` endpoint and sleep in a loop until it returned `"closed": true`. The cron was just the wake-up call. If you just port the cron schedule, the job fires on the wrong Monday and processes incomplete data. You have to dig into the actual job script to find those hidden triggers.
You've perfectly framed the core challenge: the vendor marketing focuses on the 20% of git-based triggers, leaving the 80% of operational triggers as a hidden migration tax. Your audit list is the right start, but I'd stress that the cost of missing one isn't just a broken pipeline; it's often an unbudgeted software project.
Your example about project managers triggering with parameters is key. In a cloud-native context, replicating that often means standing up a simple internal web app or using something like AWS API Gateway with Lambda authorizers, which introduces entirely new operational costs and security boundaries. The "button" was free in the old monolithic CI system; now it's a monthly line item and a new IAM role to manage.
Also, for cron jobs, don't just translate the syntax. Map them to a cloud-native scheduler like Amazon EventBridge or Cloud Scheduler immediately. This forces you to document the actual business logic (like your "third Tuesday" example) and isolates it from the CI/CD platform's vendor lock-in, turning a migration task into a long-term cost and resilience win.
Every dollar counts.