Hi ps241992,
as Steve rightly pointed it is not an easy task and not a good fit to migrate from TWS to AUTOSYS as both tools work
and behaves in a very different manner.
i along with my team mates did experience how difficult and complex the migration was, while doing the migration for one of my client and we were able to successfully migrate whole jobs from TWS to AUTOSYS but it requires alot of effort and thinking in terms of depicting TWS job behavior in AUTOSYS.
Key things that you need to take care or work from day 1 is:
1. Conversion - How are you converting the jobs from TWS to AUTOSYS? i mean you first need to create a skeleton or basic job definition as per AUTOSYS. So are you planning to do it AUTOMATIC using script or manual? Naming Convention is what you have to consider from day 1 and start setting and following those stds.
Note: once the basic job definition is ready, then that job definition will undergo so many changes to mimic TWS behavior. Similar is the case with naming conventions, you will come across with so many scenarios where in you have to add or modify the naming stds to cater to those scenarios.
2. DEPENDENCY MAPPING - In tws, one job can be called in multiple schedules, so when you are converting the jobs from TWS to AUTOSYS, you may need to understand, know and differentiate these jobs and have to validate and verify that whole job flow in AUTOSYS as per TWS. Here naming convention again plays an important role.
3. DOCUMENTATION - Documents on naming stds, test cases to demonstrate TWS scenarios in AUTOSYS, VALIDATION Documentation, Reports which can display the job flows from TWS as well as AUTOSYS. etc etc.
4. Time Frame - This migration is not as easy nut to crack and will exceed the timelines depending upon the number of jobs to migrate. in TWS, if you are referring to 100 JOBS then in autosys the count will be somewhere 150 to 200 depending upon the scenarios like in TWS there is no separate job required for a file being watched but in AUTOSYS that will be a separate job. So once the migration or jobs will be converted then we need to validate and test the executions which will take time. Decide about the timelines based on number of jobs, complexities, application team (job owners) involvements to validate the flow etc.
5. AS IS MIGRATION or SIP - Best way to handle or proceed with this project is to have a SIP(Systematic Improvement Plan) where business requirements will be understood and the jobs in AUTOSYS can be created, defined and managed as per business requirement instead of doing AS-IS migration which in turn at later stages involves SIP. So propose the project as an SIP.
6. Job ATTRIBUTE MAPPING - You have to map all attributes/behaviors of TWS in AUTOSYS. Like RECOVERY OPTIONS (CONTINUE, RERUN, PROMPT) eg. You should know how the behavior of these can be mimicked in AUTOSYS. Similarly, in TWS, one schedule can have multiple run frequencies (Multiple Calendars, individual Dates, offsets etc) where as in AUTOSYS it is not the case, so you have to consider those as well.
7. TWS Scenarios / PAIN POINTS - list down all the scenarios, requirements, pain point which you are currently facing and then work on that to cover in AUTOSYS.
There is so much to consider and list is endless.. based on my experience i will suggest in following sequence:
a. try to mitigate or cover the problem areas or business requirements in TWS only instead of migrating to AUTOSYS.
b. if you dont have choice to move from TWS, then choose CONTROL M instead of AUTOSYS as TWS and control M works in same manner.
c. if you still decided to switch to AUTOSYS, then have NON PRD instance ready first where in you can do all the testings and executions and validations in NON PRD then to PRD. When i am saying NON PRD instance ready, i mean all scripts and business/application teams shd have nonprod instances as well.
d. Do the SIP instead of AS-IS.
Hope it will help. Best of luck.