Step-by-step approach to migrate AutoSys from v12.x to v24.x (24.1.01)

 

Step 1: Confirm scope and success criteria

1. List what’s in scope: Scheduler, Web UI, DB, EEM, agents, integrations (file watchers, alarms, custom scripts).

2. Define success: “All critical jobs run successfully for N cycles, monitoring works, notifications work, no missed SLAs.”

3. Define downtime tolerance and cutover window.

---

Step 2: Inventory your current v12.x environment

1. Capture versions: AutoSys (Scheduler, agents), OS, DB, EEM, Java/Tomcat (if used), plugins.

2. Export current configuration:

   • Instance configs, environment variables, service configs

   • Job definitions, calendars, machine definitions, global vars

3. Identify custom dependencies:

   • Scripts, wrappers, external libraries

   • Integrations (SMTP, SNMP, ticketing, REST calls)

4. Identify critical workloads:

   • SLA jobs, month-end jobs, revenue-impacting flows

   • Upstream/downstream dependencies

---

Step 3: Review compatibility & prerequisites

1. Validate OS support for v24.x across Scheduler/Web/agents.

2. Validate DB version support (upgrade DB if needed).

3. Validate EEM version compatibility (upgrade EEM if needed).

4. Decide your security target:

   • Keep current mode initially, or

   • Implement TLS/mTLS + SAML2 as part of upgrade (recommended but can be phased)

---

Step 4: Choose migration method (recommended: parallel)

Option A — Parallel build (best practice)

1. Build a new v24.x environment side-by-side (new servers/VMs).

2. Migrate and test in isolation.

3. Cut over production workloads at the end.

Option B — In-place upgrade (only if constraints)

1. Upgrade components on the same servers.

2. Higher risk; rollback must be very solid.

---

Step 5: Prepare non-prod (DEV/UAT) and run a rehearsal

1. Clone or restore a copy of the v12 DB into non-prod.

2. Install AutoSys v24.x in non-prod.

3. Run DB upgrade scripts in non-prod (per vendor procedure).

4. Import/validate job definitions, calendars, machines, permissions.

5. Run sample critical workflows and validate results.

---

Step 6: Prepare production foundations

1. Provision infrastructure for v24.x (Scheduler/Web/DB connectivity).

2. Ensure DNS, firewall ports, routing, and NTP time sync.

3. Prepare certificates if enabling TLS/mTLS.

4. Prepare SSO setup if enabling SAML2 (IdP metadata, callback URLs, test users).

5. Create a detailed cutover runbook and rollback runbook.

---

Step 7: Take backups and freeze changes (production)

1. Announce a change freeze window (no job edits during cutover prep).

2. Take full backups:

   • AutoSys DB backup (validated restore)

   • $AUTOSYS directory (and config files)

   • EEM config backup

   • Custom scripts repos + server snapshots if possible

---

Step 8: Install AutoSys v24.x components (production)

1. Install Scheduler components.

2. Install/configure Web UI (Tomcat/JRE per v24 requirements).

3. Connect to DB and run DB upgrade steps (as per release docs).

4. Validate base services:

   • Scheduler starts cleanly

   • CLI commands work

   • Web UI login works (local auth/EEM/SSO depending on plan)

---

Step 9: Migrate/upgrade agents (phased)

1. Start with a pilot set of agents (non-critical hosts).

2. Validate:

   • Heartbeat/communication

   • Job execution

   • Exit codes and stdout/stderr capture

3. Expand rollout to critical tiers in waves.

4. Keep a clear backout plan per wave.

---

Step 10: Enable/transition security features (optional phased approach)

Recommended phasing

1. Go-live first with minimum change (if needed).

2. Then enable:

   • TLS/mTLS between Scheduler and agents

   • SAML2 SSO for UI/Web Services

3. Validate again after security changes (auth + job execution).

---

Step 11: Full validation (pre-cutover + post-cutover)

1. Run a “golden batch” list:

   • Critical boxes and downstream jobs

   • Calendars and date conditions

   • Event-based triggers

   • Alerts/notifications

2. Validate monitoring:

   • New Monitor views

   • Alarms visibility

   • Logs (search, comparison if used)

3. Validate integrations:

   • Email/notifications

   • Tickets/incidents

   • Any API consumers

---

Step 12: Cutover execution

1. Stop new scheduling on v12 (quiesce) at agreed time.

2. Let running jobs finish or decide controlled stop.

3. Switch control to v24:

   • Point clients/users to new UI

   • Ensure scheduling starts from v24

4. Closely monitor for at least 1–2 full business cycles.

---

Step 13: Hypercare and stabilization (first 1–2 weeks)

1. Daily health checks: service uptime, job success rates, SLA misses.

2. Fix: agent edge cases, permissions, missing libraries, path issues.

3. Capture lessons learned and finalize documentation.

---

Step 14: Decommission old v12 (after sign-off)

1. Keep v12 in read-only/standby for an agreed period.

2. Archive configs, DB backups, and audit evidence.

3. Decommission servers and revoke old credentials/certs.