Moving from DataStage to SQL in ETL mode ELT mode with a containerized buffer database Some companies are considering moving away from DataStage, IBM's popular ETL. The reasons are sometimes linked to licensing costs or process maintainability issues. But this shift mainly responds to an increasingly pressing need for performance and scalability : processes managed by historical ETLs (such as DataStage) tend to decline in favor of simple SQL or quasi-SQL processing in modern databases (such as BigQuery, Snowflake, Redshift, etc.), or via lighter ETL processes.   It is possible to automate the transition from DataStage to simple SQL or enriched SQL, in ELT mode. However, issues of readability and efficiency of the target database may arise. They can be addressed by parallelizing processes on a third-party container, within modern databases, in ETL mode.   We'll explain it to you.  Stages 1: Converting DataStage logic to SQL {openAudit}, our software, will identify transformations, extractions and loads used in DataStage jobs by detecting sources, targets, filters and transformation logics. {openAudit} will then convert DataStage transformations into step-by-step SQL queries or CTE (Common Table Expression). Having one SQL step per Stage allows for real checkpoints that don't exist in DataStage.  The entire SQL will then be adapted to comply with the specificities of the target database. These simplified SQL queries will replace the graphical components of DataStage. {openAudit} can also present a graph with all the dependencies, Stage by Stage and/or job by job.  Stage 2:  Converting DataStage ETL to  Containerized Buffered ETL Logics In this context, {openAudit} will transfer the transformation tasks to a third-party container, detached from the target database, according to the ETL logic. This approach will avoid overloading the target database in order to ensure continuity of service, especially during heavy processing or batch operations. Buffer containers  : The temporary containers will serve as intermediate storage areas where data will be loaded before transformation. This method will reduce interactions with the target database and streamline processes. This structure is modular, which provides great flexibility for maintenance, deployment and updates of DataStage jobs translated into SQL. A  parallelization of tasks:  Jobs will be executed in parallel with a “multi-threaded” architecture. This parallelization will significantly reduce processing times. Other option:  Converting DataStage ETL logic to ELT logic In this context, the approach used by {openAudit} will be to optimize and stabilize the SQL queries that will perform the transformations within the target database. The first interest will be to be able to exploit the parallel processing and optimization capabilities of the target database. The second interest will be that the centralization of processes in a unified SQL environment will facilitate the management of transformations.   CONCLUSION  Modernizing ETL processes, by migrating from DataStage to SQL processing in ELT or ETL mode, appears opportune for any company seeking to optimize its performance and the scalability of its Information System. By adopting an ELT approach or by offloading transformations to third-party containers (ETL), it becomes possible to take full advantage of the advanced processing capabilities of modern databases such as BigQuery or Snowflake. Thanks to solutions like {openAudit}, this transition is not only automated, but also readable and efficient, while massively reducing the costs associated with this modernization.