The hardest part of any project is simply getting started.

Take something totally unrelated—sewing. I love sewing because I can see the results of my work quickly. But even then, there are parts I procrastinate on. Cutting out fabric? Absolutely my least favorite step. I’ll delay that part until I have enough time and mental energy to get through it. Once the fabric is finally cut, though, the rest of the project becomes fun, fast, and deeply satisfying.

My latest example: a warm robe for my son. Thanks to a Monday holiday and a snow day Sunday, I finally carved out the time, cut the fabric, and finished the robe. Once I got started, the whole thing came together smoothly.

Modernizing z/OS development is very much the same.
In my last blog, I talked about getting started with modern development practices for z/OS applications. But “getting started” is the biggest barrier—because when you look at everything at once, it feels overwhelming.

So let’s break it down, the same way I break down a sewing project into manageable steps.

Step 1: Inventory—Know What You Have

Before you change anything, you need a clear picture of your current environment.

Understand the ecosystem:

• Which teams or groups have access to which sets of files?
• For each team, what is the full set of responsibilities?
  (This might span multiple applications or only portions of one.)
• Where is the source code actually stored?
  • Is everything in your library manager or other control systems?
  • Are some artifacts still in PDS/PDSEs?
  • Make sure you uncover all the scattered pieces.

Understand your technical processes:

• How are your builds done today?
• How are artifacts deployed?
• What are your change‑approval and audit requirements?
  (And how do they compare to those already in place for distributed applications?)

When IBM went through this journey, we discovered our procedures were still tailored to older tooling—even though our distributed side had already modernized. Once we realized this, we were able to adopt many of the newer distributed best practices on the z/OS side as well.

Getting this inventory right is foundational.
It shapes the rest of the migration.

Step 2: Infrastructure Setup

Now that you know what you have, establish the technical foundation you’ll build on.

Git server selection and connectivity

• Understand the organization’s choice of Git platform.
  (Any option can work—GitHub, GitLab, Bitbucket, etc.)
• If one hasn’t been chosen, look for features you need, such as:
  • On‑prem deployment options
    (e.g., GitLab supports this and offers a z/OS runner)
  • Integration with your automation strategy
• In IBM, we used GitHub since it was already in place across the company.
• Ensure connectivity between the Git server and your z/OS development environments.

Identity strategy for builds and deployments

• Pipelines often perform build and deploy operations, so define:
  • Will you use functional IDs?
  • How many?
    (I recommend separate IDs for each deployment environment—Dev, Test, QA, Prod—to prevent accidental misuse.)
  • Use a separate functional ID for builds.
• For user‑initiated builds, continue using individual user IDs so access is properly enforced.

This groundwork ensures the modernization process has a stable platform to grow on.

Step 3: Pilot—Start Small, Learn Fast

Choose your first team or teams wisely:

• Not the most critical applications.
• Not the least important either.
• Look for teams eager to embrace change.

This initial group becomes your learning lab.

With them, you will:

• Learn the tools and processes.
• Define or refine internal documentation.
• Develop or adopt training.
• Establish patterns for build and deploy pipelines.

In the IBM CIO Office, we used:

• IBM Dependency Based Build (DBB) – which has since added configuration‑based capabilities. https://www.ibm.com/products/dependency-based-build
• Wazi Deploy – now generally available and substantially improved. https://www.ibm.com/docs/en/developer-for-zos/17.0.x?topic=deploying-zos-wazi-deploy

The key is to select tools that:

• Integrate well with Git and USS, and
• Still understand PDSE-based build requirements.

We used a “learn → do → teach” model—something I’ll cover in a future blog.

Once the first teams are migrated, you can accelerate the rest.  This first process took us 5 months approximately, but we were working with DBB before its latest release, and with Wazi Deploy while still in development.  Your time frame may change due to increased dependencies between applications that will need to be designed for as many of the CIO applications are more independent than many client applications I have seen.  

A Practical Migration Timeline

Our typical timeline within the IBM CIO office per team ranged from 8–12 weeks, including learning the new ways of working.  One key thing I learned with this process, is we all think this takes longer than it really does.  Our teams were continuing to do their continuous development as this change was going on, but we did have two people in the pipeline team helping the teams on the process.  This work showed me what was possible with appropriate planning and setup.  

Weeks 0–2

• Learn Git and GitHub (or your selected Git server)
• Migrate the source code

Weeks 2–6/8

• Configure and test builds across all languages and middleware
• Validate source‑to‑load and object‑to‑load relationships
• Validate impact builds and dependencies
• Validate full application build
• Create versioned deployment packages
• Test synchronized deployments (pipeline and non‑pipeline)
• Perform regression tests of core functionality

Weeks 6/8–12

• Establish the new change workflow with full traceability
• Train and enable all developers, testers, and business analysts
• Validate controls, roles, and workflow behavior
• Document process changes
• Pilot production deployments
• Certify the new SCM, build, and deploy technologies
• Switch fully to the new pipeline
• Decommission the legacy process

Every team moves at its own pace—but the goal is the same:
everyone operating in the new way, with the old way fully shut down.

A Final Critical Point: Dependencies Matter

The success of this journey hinges on the initial inventory.

You need to:

• Understand cross‑team dependencies.
• Decide how “old” build libraries will interact with “new” build outputs during the transition.
• Or, if shared components move early, define how others will consume their new deployments.
• There are many discussions about how to handled dependencies one is: https://ibm.github.io/z-devops-acceleration-program/docs/dependency-management/

This hybrid/transition design happens at the start.
Once all teams are migrated, remove the temporary connections to the old system.

Closing Thoughts

Just like cutting fabric for a sewing project, the early steps in z/OS modernization feel tedious and slow. But once that foundational work is done, everything moves faster—and the results are worth it.

The key is simply to start.
Small steps. Clear structure. A plan that grows with experience.

Call to Action

If you’re considering modernizing your z/OS development practices, start your “inventory” now. Choose one application, one team, or even one process. Getting that first cut made is the beginning of real momentum.

And if you want help refining a plan, choosing tools, or outlining the training approach— join this community to learn about other resources available to help, and learn from others.  Share your experiences here if you have already started or have finished your migration and are now onto the continuous improvement phase.  

PS Blogs are coming out faster thanks to AI's assistance with writing and fixing images to the right format.