Building a Technology Transformation Factory

Executive Summary: Building a Technology Transformation Factory

How do you execute large-scale IT transformation with precision, consistency, and trust?

Transformation isn’t about a single initiative—it’s about creating a repeatable process that enables organizations to scale change efficiently. A Technology Transformation Factory provides a structured approach to executing complex programs while ensuring alignment, transparency, and stakeholder engagement.

This article is grounded in my experience leading the Application Migration Factory (AMF) at GE HealthCare, a high-stakes program that successfully migrated 1,400+ applications in just 18 months. The prologue provides context for this transformation, explaining the urgency and challenges of breaking away from GE’s corporate infrastructure. While the AMF was specific to IT divestiture, the principles behind its success are universally applicable to any large-scale IT transformation effort.

Key Takeaways from This Framework:

✅ One Source of Truth – A single, governed system of record eliminates confusion and enables confident decision-making.

✅ Stakeholder Engagement & Decentralized Ownership – Transformation succeeds when people have a seat at the table and take ownership of their role in the process.

✅ The Runbook – A living playbook ensures that everyone understands expectations and continuously refines the approach.

✅ Tracking the Work – Structured workflows reveal bottlenecks early, prevent blind spots, and maintain momentum.

✅ Transparency Through Reporting – Real-time dashboards remove emotion and politics, enabling data-driven execution and accountability.

These five rules create a scalable, disciplined approach to IT transformation—whether it’s modernization, cloud migration, AI adoption, or reducing technical debt.

Read on to learn how to design, implement, and scale your own transformation factory.

Prologue

For the past two years, I had the opportunity to lead the Application Migration Factory (AMF) for GE HealthCare, a massive effort to replatform 1,400+ business applications in just 18 months. The stakes were high—these migrations were a prerequisite for on-time TSA exits.

Transition Service Agreements (TSAs) ensure that the parent company continues to provide critical services to a divesting entity for a limited period. Exiting a TSA on time is crucial because delays can result in significant financial penalties and operational disruptions. Given the compressed timeline, there were serious concerns about whether we could execute successfully.

A Unique Perspective on the Migration

Before joining GE HealthCare, I was a Principal Architect at GE Corporate, where I supported numerous shared services, particularly in financial systems and data analytics. This experience proved invaluable—HealthCare not only needed to migrate its own applications (~1,000 apps hosted on GE’s core services), but it also had to replicate shared service applications for functions like HR, Legal, Tax, Financial Reporting, and Payroll. These corporate functions had previously been centralized under GE but now needed to be stood up independently for GE HealthCare.

At GE Corporate, I had already begun assessing the application landscape, mapping critical dependencies, and defining migration strategies. Then, suddenly, my role shifted: I was asked to join GE HealthCare as an Enterprise Architect and play a role in their migration efforts. Essentially, I went from being the pitcher of applications at Corporate to the catcher at HealthCare.

Stepping Into the AMF Leadership Role

Shortly after joining HealthCare, an organizational reshuffle left me in a position where I had to define my own role. One day, a brief phone call from a colleague—who was struggling to get data from the “Application Migration Factory”—set me down a rabbit hole. I quickly discovered that while the AMF was being developed at Corporate, it hadn’t fully taken root at HealthCare yet.

Recognizing the urgency, I took the initiative to fly out to Milwaukee, WI, for the first TSA exit workshop—a high-stakes gathering of technology leaders strategizing how to separate from GE on time. The AMF was only one piece of the divestiture puzzle—other critical efforts included:

• Building an entirely new network

• Establishing a new identity provider

• Physically migrating out of data centers

• End-user device transitions (PCs & mobile devices)

• Standing up temporary infrastructures

• Negotiating countless service agreements with vendors

“Who is Representing the AMF?”

During the workshop, the conversation eventually turned to Application Migration. The facilitator posed a critical question:

“Who is representing the Application Migration Factory?”

Silence. People glanced around the room. Consultants whispered. No one stepped up.

Never one to back down from a challenge or ignore an opportunity, I raised my hand and said, “I’m here for the AMF.”

At the time, I didn’t know many people in the room, but I recognized a few key faces whom I believed would back me up. I introduced myself and explained:

“I recently transferred from Corporate, where I was an architect on the GE AMF. I’ll be leading the program from a technical standpoint, establishing the target architecture and framework for application migrations.”

No one objected. And just like that, my role for the next 2 years was locked in.

Laying the Groundwork for Success

During the next break, the EY consulting team approached me—they wanted to meet ASAP to discuss my plans for the AMF. That was the first of many meetings where we laid the foundation for what would ultimately become a highly successful migration program. Over the next 24 months, we built and executed the Application Migration Factory, ensuring that every business application migrated on time, allowing GE HealthCare to successfully exit its TSAs.

Introduction

The concept of a Technology “Factory” may bring different images to mind. Is it an assembly line churning out innovations at scale? Does it require everyone to be co-located, working in perfect synchronization? How is work delegated, and how are schedules established? These are just a few of the many questions that arise when designing an effective, repeatable technology delivery model.

In this article, I will share my experience leading GE HealthCare’s Application Migration Factory (AMF)—a structured framework that defined the rules of engagement for all stakeholders involved in the company’s IT divestiture. Splitting off a Fortune 500 company from its parent organization is an incredibly complex undertaking. Success depended on coordination across leadership, core IT services, business users, application owners, regulatory compliance teams, and many others—all working toward a common goal under strict deadlines.

I’m sharing these insights not just because AMF was a success story, but because the lessons learned apply to any large-scale IT transformation initiative. Whether you’re:

• Introducing new technology like AI,

• Retiring legacy systems to reduce technical debt, or

• Driving modernization efforts to cut costs and increase agility,

… the underlying organizational challenges remain the same. Transformation affects day-to-day business operations, requires cross-functional alignment, and demands disciplined execution.

The rules I developed through my AMF experience serve as a foundation for any IT transformation program. These principles draw from proven architecture methodologies and embrace servant leadership, ensuring that transformation:

• Engages the entire organization,

• Respects the individuals doing the work,

• Prioritizes strategic goals, and

• Maintains focus on timelines and execution.

As transformational leaders, we have an obligation to drive change in a way that is structured, scalable, and impactful. These rules will help you do just that.

Rules

Rule #1: One Source of Truth

IT transformation is complex, fast-moving, and high-stakes. Without a single, accurate source of truth, confusion sets in, mistakes happen, and execution suffers.

The Spreadsheet Chaos – A Lesson from AMF

During our first Application Migration Factory (AMF) meeting at GE HealthCare, we started by reviewing the Master Application Inventory (MAI)—a spreadsheet provided by GE Corporate. It contained thousands of rows and dozens of attributes representing applications either owned by HealthCare or critical to its operations.

Within minutes, someone interrupted:

“Wait! This is an old copy.”

They immediately switched to their inbox to search for a more recent version. A few minutes later, another team member opened yet another spreadsheet—a HealthCare-maintained copy with additional fields. It wasn’t long before multiple people were working off different versions, each stored in different locations.

At the end of that meeting, I established Rule #1: One Source of Truth—and No Spreadsheets!

The Spreadsheet Problem

I love spreadsheets as much as anyone. They’re versatile and great for point-in-time analysis. But spreadsheets are not a system of record. Here’s why:

✅ Lack of version control – Too many copies, leading to data inconsistency.

✅ Limited access governance – Anyone can modify, overwrite, or delete key data.

✅ Limited to no audit trail – No visibility into who made changes or why.

✅ Static Data – Spreadsheets don’t update dynamically and require manual maintenance.

At our second meeting, someone pulled up the MAI spreadsheet again. I stopped the discussion and asked, “What’s Rule #1?” The team hesitated before responding:

“Wait… you were serious about that?”

Yes, I was. And once we eliminated spreadsheets, our ability to execute improved dramatically.

Implementing a True System of Record

To enforce a single source of truth, we leveraged LeanIX, an Enterprise Architecture Management (EAM) system that provided:

✔ SSO-based access controls – Ensuring only the right people could edit data.

✔ Audit logs – Tracking when changes were made, by whom, and what was modified.

✔ Mandatory commentary – Every data update required an explanation.

✔ Collaboration features – To-do lists, stakeholder notifications, and surveys streamlined engagement.

✔ Governed data fields – Preventing arbitrary changes to critical records.

This one change alone—shifting from spreadsheets to an authoritative, governed system—transformed the way we operated.

Your Transformation Program Needs a System of Record

I’m not saying you have to use LeanIX—there are plenty of great tools out there. What I am saying is:

❌ No spreadsheets.

❌ No PowerPoint for tracking real-time data. (More on that in the status reporting discussion.)

✅ Use a tool designed for structured data governance and collaboration.

A well-governed single source of truth builds trust, improves execution, and prevents costly missteps—all essential for driving successful IT transformation.

Rule #2: Stakeholder Engagement and Decentralized Ownership

Stakeholder engagement is one of the most critical elements of a transformation program. And let’s be clear—stakeholders aren’t just senior leaders. They include everyone involved—whether they contribute to, are responsible for, or are impacted by the transformation.

One of the most common phrases heard in transformation programs is:

“People don’t like change.”

I don’t believe that. Who doesn’t like getting a new car?

Your stakeholders don’t dislike change—they dislike uncertainty. The key to reducing uncertainty is building trust. And trust is built through clear communication, meaningful engagement, transparency, and shared ownership.

Building Trust Through Stakeholder Engagement

Stakeholder engagement is not a side activity—it is core to the success or failure of a transformation program. Too often, teams treat it as an afterthought, saying:

“I don’t have time for this—I have actual work to do.”

That mindset kills transformation efforts. A program that loses stakeholder confidence will struggle—or fail outright. But a program that actively engages stakeholders can rally support, streamline execution, and sustain momentum.

Here’s how to engage stakeholders effectively:

✅ Identify & Classify Stakeholders – Build a comprehensive stakeholder list with clear RACI (Responsible, Accountable, Consulted, Informed) roles.

✅ Develop a Communication Plan – Define how each cohort of stakeholders should be engaged.

✅ Use Multiple Communication Channels – Every group should have at least two ways to receive updates (pro tip: don’t rely solely on email. Utilize social media style updates, schedule recurring office hours, leverage the company’s communication team).

✅ Create a Feedback Loop – Give stakeholders a forum to ask questions, share concerns, and provide input.

Decentralized Ownership: Skin in the Game

Beyond communication and trust, successful transformation programs require stakeholders to have real ownership. When people have skin in the game, they are more invested in the program’s success.

This must be balanced—you don’t want to introduce unnecessary bureaucracy or waste people’s time—but stakeholders need a seat at the table. They must have a voice in decisions, the ability to raise concerns, and the responsibility to help drive success.

How We Applied This in AMF

For the Application Migration Factory (AMF), we created a steering committee that included representatives from each core service. This ensured that:

✔ All teams understood each other’s requirements.

✔ Processes were optimized. (For example, if two teams needed similar information from an application owner, we streamlined the outreach.)

✔ Cross-team conflicts were minimized.

Avoiding “Grenades”—Why Cross-Team Visibility Matters

One major benefit of structured stakeholder engagement is that it prevents unexpected disruptions. Every transformation program has at least one moment when a team—often compliance, legal, or security—drops a new non-negotiable requirement that threatens to derail the timeline.

They don’t do it on purpose. But without a structured forum for engagement, it often feels like they’ve thrown a grenade into the middle of the program and walked away.

By ensuring these teams were part of the steering committee, we avoided last-minute surprises. Instead of finding out too late that a new security policy, regulatory requirement, or legal mandate would cause delays, we had an opportunity to address it in real time—discussing solutions before it became a roadblock.

The Power of Ownership & Collaboration

When stakeholders are engaged, informed, and accountable, the entire organization benefits:

✔ Ownership drives pride and accountability.

✔ Transparency prevents unnecessary delays.

✔ Collaboration enables real-time problem-solving.

✔ Teamwork fuels transformation success.

Stakeholder engagement is not just a best practice—it’s a requirement for successful IT transformation.

Rule #3: The Runbook

As my friend Edward Roske says, “90% of people are 90% good.”

When people deviate from expectations, it’s rarely out of defiance or malice. More often, it’s due to a lack of clear guidance. In the absence of direction, successful people will find a way to be successful—but their approach may not align with the broader transformation effort.

If we want teams to deliver consistently, we must equip them with the right information and tools. In a transformation program, that means providing a clear, accessible, and continuously evolving runbook that defines the do’s and don’ts of the process.

Building the Runbook – A Collective Effort

Creating a runbook isn’t a top-down exercise—it requires stakeholder collaboration and decentralized ownership (see Rule #2). Each team involved in the transformation is responsible for contributing its portion of the runbook, outlining:

✔ What is expected of them to successfully move through each transformation phase.

✔ What deliverables are required at each tollgate or milestone.

✔ What processes, tools, and documentation must be followed.

The central transformation team plays a critical role in:

✅ Ensuring the runbook is structured, clear, and consistent.

✅ Resolving conflicting requirements between teams.

✅ Maintaining a single, accessible version of the runbook.

Making the Runbook Usable

A runbook is only effective if it’s:

✅ Easily accessible – All stakeholders should be able to find and use it quickly.

✅ Searchable & interactive – Content should not be buried in static files.

✅ Continuously updated – It should be reviewed and refined as the transformation evolves.

For the Application Migration Factory (AMF), we used a SharePoint site as our primary portal for all program-related information. Rather than relying on static documents, we structured the runbook like a wiki, ensuring content was:

✔ Searchable – Stakeholders could quickly find answers without digging through PDFs.

✔ Easy to update – Teams could collaborate in real-time to refine guidance.

✔ Augmented with an FAQ – A dynamic FAQ captured recurring questions and lessons learned.

Leveraging AI for an Intelligent Runbook

With access to Copilot Studio and other agentic AI tools, it’s now easier than ever to create program-aware chatbots that provide instant answers to stakeholder questions. A well-structured runbook, combined with an AI-powered assistant, can significantly accelerate adoption by enabling teams to self-serve information rather than waiting for answers.

The Runbook is a Living Document

A runbook isn’t something you write once and forget. As Dwight Eisenhower famously said:

“Plans are useless, but planning is indispensable.”

The purpose of a runbook isn’t to create a 100% perfect plan from day one—it’s to ensure that everyone is continually engaged in refining the transformation process. As new challenges emerge and solutions are found, the runbook must evolve in real-time, capturing lessons learned and best practices.

When people know the ground rules and where to find the information they need, compliance becomes the default behavior, not an afterthought. A well-maintained runbook is a blueprint for consistency, efficiency, and successful transformation execution.

Rule #4: Tracking the work

For a transformation program to succeed, transparency and awareness are critical. You must always know:

✔ What’s happening and where things stand in the process.

✔ Where bottlenecks are occurring and what’s causing them.

✔ Where resources may be underutilized or overstretched.

Transformation is a trust-building exercise, and stakeholders—especially leadership—expect clear progress tracking against stated goals and deadlines.

Why Tracking is Essential

All programs encounter problems and delays—that’s unavoidable. What separates successful programs from struggling ones is how well they anticipate and respond to those challenges.

When leadership is blindsided by:

❌ Missed deadlines with no prior warning

❌ Last-minute requests for additional resources or funding

… trust erodes quickly. On the other hand, when leaders see:

✅ Proactive problem-solving

✅ Early identification of risks

✅ Clear reasoning for any necessary adjustments

… they gain confidence in the process.

I like to use the analogy that running a transformation factory is like being an air traffic controller:

✈️ Who’s taking off? (What work is just starting?)

✈️ Who’s in the air? (Where is each initiative in its journey?)

✈️ Who’s landed? (What’s been completed?)

Without real-time tracking, everything descends into chaos.

Turning the Runbook into a Workflow

Your Runbook (see Rule #3) serves as the blueprint, but you need a workflow tracking system to operationalize it.

An effective workflow provides:

✔ Visibility – Real-time updates on progress.

✔ Accountability – Clear ownership of tasks.

✔ Problem Identification – Early warnings when things go off track.

Balancing Detail vs. Usability

A good tracking system requires balance:

🔹 Too many tollgates? The process becomes cumbersome and frustrating.

🔹 Too few tollgates? You lose the ability to track meaningful progress.

The goal is to capture enough data to provide actionable insights without turning workflow management into a bureaucratic nightmare.

Managing Sub-Processes and Multiple Systems

In an ideal world, all tracking happens in one system. In reality, that’s not always possible.

During AMF, we didn’t have time to build one centralized workflow system that covered the entire runbook across all core services. Instead, we had to:

✅ Establish a master ticketing system to track major tollgates.

✅ Allow sub-processes to manage more complex workstreams (e.g., infrastructure requests).

✅ Ensure that teams using separate systems had a clear connection back to the central workflow.

The key to making this work? Clear communication and accessibility.

When users had to exit one platform and enter another, we:

✔ Built documentation directly into the workflow with links and instructions.

✔ Explained inefficiencies transparently so people understood why things were done a certain way.

Even when processes aren’t perfect, explaining the “why” and showing that the team is working to simplify things goes a long way in maintaining stakeholder buy-in.

Rule #5: Transparency Through Reporting

The final rule for building a transformation factory is establishing a solid reporting environment—one that provides real-time transparency across the entire program.

A fully functioning data & analytics environment is not just a nice-to-have—it’s critical for:

✔ Telling the transformation story.

✔ Keeping stakeholders informed and engaged.

✔ Building trust through objective, data-driven insights.

The Problem with Static Reports

Let’s go back to Rule #1, where I banned spreadsheets. Well, I also banned PowerPoint for AMF updates.

To be clear, PowerPoint didn’t disappear entirely—it proved even harder to eliminate than Excel. But if someone was reporting AMF numbers in a presentation, those numbers had to come from our reporting environment—not from manually updated slides.

Static, file-based updates don’t cut it in transformation programs. Why?

❌ Data gets outdated instantly.

❌ Subjectivity creeps in.

❌ People question the numbers instead of solving problems.

Building the AMF Reporting System

To provide real-time visibility, we evaluated different options:

• Reporting directly from LeanIX? It lacked key data, particularly from our ticketing system.

• Pulling everything into ServiceNow’s CMDB? Not feasible—too many external dependencies.

• Consolidating into the data lake? Too slow and costly given our timeline.

Given time constraints, cost, and resource availability, we took a pragmatic approach—we built a standalone datamart in Azure SQL Server.

How It Worked

✔ A small team of SMEs integrated data from 3-4 key systems, including:

• LeanIX (Enterprise Architecture data).

• ServiceNow CMDB (infrastructure and ticketing data).

• Other critical process tools.

✔ We then leveraged Power BI to create dashboards for real-time visibility.

✔ Within weeks, all AMF updates were sourced from live dashboards.

The Power of Real-Time Reporting

With a single, trusted reporting source, everything changed:

✔ Issues were no longer debated—they were diagnosed in real time.

✔ Leadership updates became interactive—if an app missed a deadline, we could drill down live to show exactly what happened and how we were fixing it.

✔ Accountability increased—we even built a leaderboard to track which departments were on target and which needed more engagement.

From Finger-Pointing to Problem-Solving

Early on, subjectivity and stress dominated AMF discussions. When problems arose, teams would:

❌ Speculate on root causes.

❌ Make emotional or political arguments.

❌ Point fingers instead of solving problems.

Once real-time dashboards became the norm:

✅ Trust in the data replaced gut feelings and assumptions.

✅ Problems became objective and solvable.

✅ Leadership stopped reacting emotionally and started making proactive decisions.

The Bigger Impact: Turning Detractors into Allies

A well-designed reporting system doesn’t just track progress—it rallies the organization.

✔ Stakeholders don’t have to wait for weekly updates—they can check status anytime.

✔ Visually compelling dashboards make progress clear and goals tangible.

✔ Detractors stop resisting and start rooting for success, helping clear obstacles instead of creating them.

When people trust the data, scaling transformation becomes easy.

Conclusion

Building a Technology Transformation Factory is not about rigid control or bureaucratic oversight—it’s about creating a scalable, repeatable system that drives real change while maintaining agility, trust, and alignment across an organization.

Transformation is complex. People resist uncertainty, not change. Leadership expects progress, not surprises. Teams need clarity, not confusion. The five rules outlined in this article serve as the foundation for managing these dynamics, ensuring that transformation programs are structured, transparent, and effective.

• One Source of Truth: Remove the guesswork—establish a single, governed system of record to drive alignment.

• Stakeholder Engagement & Decentralized Ownership: Transformation is a team effort—give people a seat at the table and skin in the game.

• The Runbook: Provide clear guidance—a living playbook that evolves as the program progresses.

• Tracking the Work: Avoid blind spots—use structured workflows to identify risks before they become roadblocks.

• Transparency Through Reporting: Data removes emotion—use real-time insights to drive accountability, trust, and decision-making.

The Application Migration Factory (AMF) at GE HealthCare was a high-stakes, high-pressure transformation effort that proved these principles work. They allowed us to scale, adapt, and execute—turning a daunting 18-month challenge into a measurable success.

The Broader Implication: Scaling Transformation Beyond AMF

The five rules in this framework apply far beyond application migrations. Whether modernizing an IT landscape, implementing AI, optimizing cloud operations, or reducing technical debt, the core challenge remains the same:

✅ How do you drive change at scale without losing control?

✅ How do you enable innovation while ensuring governance?

✅ How do you maintain momentum while managing complexity?

A transformation factory answers these questions by creating a structured but adaptable process—one that balances standardization with flexibility and discipline with creativity.

Final Thought: The Power of Execution

Transformation is not just about ideas, strategy, or technology—it’s about execution. A well-designed framework ensures that transformation doesn’t just start strong but delivers results.

Organizations that embrace these principles don’t just navigate change—they own it. And the leaders who implement them don’t just react to disruption—they define the future.

If you’re leading transformation, remember: Structure enables scale. Trust fuels momentum. Transparency creates success.

The question now is—how will you build your transformation factory?