Automic Workload Automation

 View Only

  • 1.  Automic upgrade from V21.04 to V24.4.4

    Posted 10 days ago

    Hi Community,

    Find below upgrade strategy is correct ?

    since my automic is hoted on aws

     Automic Upgrade Strategy  
     
    Parallel Application Deployment & Side-by-Side Client Migration (Zero-Downtime Strategy) 

    Step 1: Provision the Parallel App Environment 

    • Provision two brand new AWS Linux instances specifically to host the new Automic v24.4 environment. 

    • Install Java 17 (or Java 21) and deploy the unzipped Automic v24.4 installation packages onto these instances. 

    • Result: The original v21 Automic servers continue running production workloads completely untouched. 

    Step 3.2: Initialize the Compliant UTF-8 Database Target 

    • The Old System Stays Live: Your current v21 Automic engine stays online on your old AWS instances, running jobs and connecting to your old US7ASCII RDS database. 

    • Take the First Clone: You run Oracle Data Pump (expdp/impdp) to copy everything to your new AL32UTF8 RDS instance. (this will copy my execution history) 

    • Install the New System: You install the v24.4 package on your two new AWS Linux instances and point them to the new database. 
      Oracle Data Pump (expdp/impdp) operates entirely at the database layer. It doesn't care about Automic's version; it simply duplicates all physical data inside the schema. Because of this, it captures everything: 

    ->All historical execution data and logs (Statistics and Reports). 

    ->All user definitions and client variables. 

    ->Every single defined object (Workflows, Jobs, Calendars, VARA). 

    ->All Agent name registrations and settings stored in the system tables. 

    When the import into your new AL32UTF8 instance completes, you will have a perfect twin of your v21 environment. 

    • Run the Upgrade Utility: You run the Automic AE DB Load tool against the new database to upgrade it to v24.4.(The utility will then step through the schema upgrades sequentially, modifying table columns, rewriting system indexes, and adding new v24.4 specific fields without modifying or altering your existing objects or historical records.) 

    • Login and Test: You log into the new v24.4 Automic Web Interface, verify your workflows are intact, and perform all your staging tests. 
       

    During this entire test phase (which can take days or weeks), your production environment continues running on v21 without a single second of interruption. 

    . 

    Result: Both the Old (v21) and New (v24.4) Automic engines are running concurrently on separate infrastructure stacks. 
     
     
     
    NOTE: once we done with all cutover application wise into new upgraded automic version after final confirmation we can stop the old version automic ec2 instances and RDS 

     



  • 2.  RE: Automic upgrade from V21.04 to V24.4.4

    Posted 10 days ago

    You did not write it explicitly but i assume the AWI for v24 will be on the AE servers and configured properly to point to the instance.
    Also you did not facture the agents.
    You will heave to either install parallel agents and connect them to the new AE or amend the current agents to point to the new system (JCP) or fiddle with the DNS entries so the new AE server will have the name/IP of the old.
    Only in the case of parallel agents you will have two completely separate and functional environments.

    Ive done something similar last year but decided to not copy the full DB but only export the whole client via DB Unload Utility.



    ------------------------------
    ------------------------------
    Automic SME @ DXC.Technology
    ------------------------------
    ------------------------------



  • 3.  RE: Automic upgrade from V21.04 to V24.4.4

    Posted 10 days ago

    Thanks for the great feedback

    1. AWI: Yes, the v24.4 AWI will sit on Tomcat on the new web EC2  instance, explicitly pointed to the new v24.4 JCP endpoints on new app ec2.

    2. Agents: We are going with your suggestion to amend the current agents. We will update the agent .ini files in phased batches under a controlled Change Request (CR) window. This gives us a gradual cutover and an easy rollback path.

    3. Database: We are using a single Oracle Data Pump clone (expdp/impdp) to handle the US7ASCII to AL32UTF8 conversion on the fly, followed by the AE DB Load utility to upgrade the schema to v24.4.