Leading a Controlled QMS Transition: Strategy, Stakeholders, and Execution
For many medical device companies, the need to modernize a quality management system becomes obvious long before the path forward does.
Maybe your Quality Management System (QMS) still relies on paper, spreadsheets, shared drives, or a legacy eQMS that no longer fits how the business actually works.
Maybe document control has become a bottleneck.
Maybe teams are spending too much time chasing signatures, reconciling records, or working around process gaps that were manageable when the company was smaller but now create real drag.
Or maybe the trigger is more urgent: an audit finding, a complaint trend, a scaling milestone, or the realization that the current infrastructure will not support where the business needs to go next.
That is exactly why conversations around paper QMS to eQMS transitions and the difference between a QMS and an eQMS matter so much for MedTech teams right now.
The instinct in that moment is often to frame the move as a software project. Choose a system. Configure it. Migrate the documents. Train users. Go live.
That framing is where many teams get into trouble.
A QMS transformation is not simply a technology replacement. It is a business change initiative that touches processes, documentation, training, cross-functional coordination, and compliance. If the broader organization does not understand what is changing, why it is changing, and how daily work will be affected, the technology alone will not carry the project.
That is especially true when the same teams expected to lead the transition are also responsible for keeping the business running.
This article draws on expert insights from Axel Strombergsson and Vanessa Oglesby of Veeva Systems, whose deep experience across MedTech quality and QMS transformations help illuminate not just why these projects can be difficult, but how to plan and lead one in a way that reduces disruption, maintains control, and sets your team up for long-term success.
A QMS Transformation is not just a software implementation
One of the most important mindset shifts in a QMS transformation is recognizing what is actually changing.
Yes, the software matters. But the software is not the full story. A QMS transformation affects business processes, cross-functional handoffs, documentation practices, training expectations, decision-making, and your company’s overall compliance posture. It changes how work gets done and how that work is controlled.
That distinction matters even more in today’s regulatory environment. FDA’s Quality Management System Regulation (QMSR) became effective on February 2, 2026, aligning 21 CFR Part 820 with ISO 13485:2016. FDA has also made clear that device manufacturers remain responsible for maintaining an effective and compliant quality system and are still subject to FDA inspection.
In the EU, all device manufacturers are subject to on-site audit by their Notified Body prior to receiving CE mark and thus the approval to commercialize their device.
For MedTech companies, that means the real challenge is not simply getting a new platform live. It is making the transition in a way that preserves control, reduces disruption, and sets your organization up to operate better in the future state.
Creating the business case for QMS modernization
The internal case for changing quality systems usually starts building long before leadership formally commits to a project.
Operational pain starts to spread
Sometimes the pressure is operational. Current processes are too complex, inefficient, and not harmonized. Employees get pulled into low-value tasks that do not move the business forward. What starts as friction in one function can gradually become a broader organizational issue.
Teams spend energy on workarounds and manual effort instead of focused, value-added work. Once that pain starts showing up across departments, it becomes much harder for leadership to ignore.
Compliance issues make the risk harder to ignore
Sometimes the pressure is reactive. Audit findings, complaints, or broader compliance concerns can be the driving force for leadership to take a harder look at the current state. Once the consequences of a fragmented or poorly controlled QMS become tangible, compliance stops feeling theoretical and starts becoming a strategic priority.
That context is even more relevant in a post-QMSR environment, where FDA has continued clarifying inspection expectations and device inspection priorities. See FDA’s QMSR and risk-based inspections town hall page for additional context.
Growth can expose the limits of the current system
Sometimes the trigger is strategic. A startup preparing for commercialization, a company scaling manufacturing, or a business planning to add another product line may realize that the current quality infrastructure will not support the next two to three years of growth.
In those cases, the decision is not just about solving today’s pain. It is about building the operational foundation the business will need tomorrow and in the future.
Metrics make the case stronger
Whatever the trigger, the business case gets stronger when teams quantify it. Start with baseline metrics for the current state, document specific pain points, and define the value the future system is expected to create.
That kind of before-and-after framing turns vague frustration into something leadership can evaluate, prioritize, and fund.
Then, three and six months after go-live, revisit those metrics and assess whether the change actually delivered on its promise.
Start with project discipline, not just QMS selection
Once the decision is made to transition to a new quality system, the next step is to stop thinking like a buyer and start thinking like a project leader.
A QMS transformation needs the same discipline you would apply to any major operational initiative. You would not launch a major manufacturing or infrastructure project without a plan, defined ownership, and a clear understanding of what success looks like.
The same logic applies here. Leadership sponsorship, stakeholder definition, governance, communication planning, and execution tracking are not administrative extras. They are the structure that keeps the transition controlled.
This approach also aligns with broader project governance best practices, which emphasize accountability, stakeholder communication, and clear decision-making throughout the life of a project.
Leadership sponsorship needs to define the project boundaries
Upper management needs to define the project boundaries early, communicate them clearly, and stand behind them. Without that support, projects expand in every direction. New requests get layered in, timelines stretch, and budgets start exceeding what was originally approved.
The issue you’re trying to avoid is not only scope creep. It is misalignment. If leadership sets expectations one way at the start but allows the project to drift later, the whole team loses its point of reference.
Planning documents are critical to reduce ambiguity
This is where project structure matters. A project charter, clear objectives, high-level milestones, roles and responsibilities, a RACI chart, and a documented definition of success all help create alignment before the more complex parts of execution begin.
It is also helpful to put supporting project tools in place early, such as change documentation, a detailed schedule with dependencies, a RAID log, and regular status reporting. These tools make it easier to see where decisions are needed, where risks are building, and where timelines may start slipping.
The goal is not paperwork for its own sake. It is reducing ambiguity before ambiguity turns into delay or rework.
Decide what to migrate and what to leave behind
One of the most practical decisions in the planning phase is deciding what actually belongs in the new quality system.
Not every document should make the trip. Some companies may have a manageable number of records. Others may be dealing with thousands or even tens of thousands. The more useful question is not how to move everything, but what truly needs to be active, revised, and maintained in the future state.
Current procedures, work instructions, and records supporting active products may belong in the new environment. Legacy documents that still need to be retained for compliance but will not be actively touched may be better archived in a controlled, retrievable way.
That decision alone can significantly reduce migration burden.
Equally important, companies need to resist the urge to recreate old inefficiencies in a new tool. A migration is not just a change in location. It is a chance to remove waste, streamline handoffs, clarify decisions, and improve the way work actually gets done.
Remember this: if you try to force the future state to mimic the old one, you will miss one of the biggest opportunities the project offers.
Build the right governance model and cross-functional team for your QMS transition
A strong project team is not necessarily a large one. It is a well-structured one.
In larger organizations, that often means a layered governance model led by a:
- Project sponsor
- Steering committee
- Decision-makers
- Core cross-functional team
Functional leads should gather input from their respective groups and bring it back into the project structure, rather than trying to crowd every meeting with every impacted person.
In smaller startups, the structure may be less formal simply because the company itself is small. But the need for clarity does not go away.
What should not be overlooked are the people closest to the work. Shop floor stakeholders and day-to-day operators may not sit at the top of the org chart, but they are often the people who will use the new system most heavily and feel its strengths or weaknesses first.
If they are ignored until rollout, adoption gets harder. If they are involved early enough to shape requirements and surface practical realities, the future state will have a stronger foundation.
Create a communication plan early and use it throughout the QMS transition project
Communication needs to be treated as a dedicated part of the project, not something handled informally along the way. A strong communication plan defines who needs what information, when they need it, and how it should be delivered.
Leadership may need milestone-based updates. Core teams may need weekly working sessions. End users need practical explanation of what is changing, what stays the same, and what the shift means for their role.
Emails, lunch and learns, and team-level updates can all play a part. The key is consistency. Over-communicating is almost always safer than under-communicating.
This becomes especially important because communication failures tend to show up late and expensively. If affected teams are not informed early enough, they may raise concerns only after key decisions have already been made. That creates rework, delay, and frustration that good communication could have prevented in the first place.
Expect operational disruption and plan for “the messy in-between”
Even with strong planning, there is no such thing as a disruption-free transition.
Normal business does not stop because your QMS project is important. Product still has to ship. Quality work still has to continue. Audits can still happen and pull critical people away. Some organizations budget for business backfill so project team members can focus on the transition while others maintain day-to-day operations.
Even well-managed transitions come with a messy in-between period where old and new ways of working overlap, timelines get pressured, and teams are asked to absorb change while still keeping the business running. A successful project does not eliminate that reality. It plans for it.
That realism should show up in the cutover plan as well. A solid cutover plan maps the activities required to move from the old system to the new one successfully.
That includes making sure the right documentation is in place, the right training has been completed, and the team has clearly defined what must happen after validation is complete in order to move safely into the new environment.
In practice, a good cutover plan is where project planning becomes operationally concrete.
Use validation and execution discipline to catch problems early
Execution discipline matters just as much as planning discipline.
Software validation is one of the clearest examples. It becomes far more effective when the team has done a good job upfront defining requirements and building user stories around the actual business process.
Validation should not be reduced to checking whether a field exists on a screen. It should demonstrate that the system will meet end-user expectations in the context of how work actually gets done.
That thinking aligns well with FDA’s computer software assurance guidance for production and quality management system software, which describes a risk-based approach for establishing confidence that production and QMS software performs as intended.
Regular project cadence matters here, too. Weekly follow-up, clear ownership, issue tracking, and ongoing review of status and decisions are what keep the project from quietly drifting off course.
Prepare users for go-live, not just the new QMS technology
As go-live approaches, readiness becomes less about the technology and more about the people using it.
True readiness means users know what is happening, have received enough communication and training to feel comfortable, and enter go-live prepared rather than surprised. It also means looking beyond launch-day completion and thinking about practical usability once the system is live. End-user feedback, record volumes, processing activity, and closure rates can all help reveal whether the new environment is actually helping people work more effectively.
That is also why training has to go beyond software clicks. Revised SOPs and work instructions need to be in place ahead of go-live, and teams should consider quick reference guides or other self-service resources to support end users at any moment they need help. Those supporting tools often do more to drive adoption than a one-time training session alone.
For companies still building foundational quality processes, this guide to QMS setup for MedTech startups can help reinforce what strong process readiness looks like before and after implementation.
Measure success after go-live and keep improving
It is important not to confuse go-live with success.
A system being live does not necessarily mean the project has been 100% successful, nor delivered the expected value. The immediate post-go-live support period matters. Teams need to resolve what surfaces immediately after launch and make sure those issues are addressed to business expectations before formally closing out the project.
They also need to compare post-go-live performance against the baseline metrics established before implementation and revisit value realization again at three and six months. And even then, the work is not finished. Some requirements will inevitably be deferred. Some ideas will only emerge once users start working in the system every day.
Maintaining a backlog, prioritizing what was not implemented during the initial rollout, and continuing to improve the system over time is part of what turns a successful go-live into long-term operational value. Day one does not need to be perfect. It needs to be stable, usable, and strong enough for continuous improvement.
The real goal of a QMS Transformation
You are not modernizing your QMS because new software is inherently exciting. You are doing it because the old environment is too fragmented, too manual, too inconsistent, or too limiting for the business you are trying to build.
The companies that handle these projects the best are not the ones that focus only on the technology. They are the ones that treat the move as a controlled organizational change, plan for the messy in-between, prepare people as carefully as they prepare the system, and keep measuring value after go-live.
A successful QMS transition is not the moment the system turns on. It is the moment your business can operate in the new environment with greater efficiency, better control, and a stronger foundation for growth.
If your team is ready to move away from paper, spreadsheets, or a legacy eQMS, QuickVault gives MedTech companies a faster path forward with pre-configured workflows, built-in compliance support, and no lengthy customization project required. It is designed to help teams get started quickly, reduce implementation burden, and scale on a connected platform built for the full product lifecycle. Learn more by booking your free demo today ➔
Article Contributors
Vanessa Oglesby
Expert Advisor, Quality Business Consulting, Veeva Systems
Vanessa brings over 30 years of experience in the pharmaceutical and life sciences industries, with deep expertise in quality management systems, business transformation, and enterprise process improvement. Her work has spanned core QMS processes such as post-market complaint handling, nonconformance and deviation investigations, CAPA, and change management, giving her broad experience in helping organizations strengthen quality operations and improve process effectiveness across regulated environments.
Throughout her career, Vanessa has played a leading role in QMS and IT transformation initiatives that unified disparate quality processes, reduced operational complexity, and supported more connected ways of working across quality, regulatory, and operations. With experience in both business and system ownership roles, she brings a practical, well-rounded perspective on how organizations can navigate complex transitions, maintain continuity, and build stronger foundations for long-term quality and operational success.
Axel Strombergsson
Vice President of QuickVault, Veeva Systems
Axel brings over 20 years of diverse experience in the MedTech industry, spanning R&D leadership, operations, regulatory strategy, and medical device commercialization. Before joining Veeva, Axel led R&D efforts for a surgical device company and later transitioned to roles focused on scaling operations and bringing medical devices to market. He also worked at Vanderbilt University’s Tech Transfer Office, where he collaborated with research teams on cutting-edge medical device innovation.
As an integral part of multiple MedTech startups, Axel has gained firsthand experience in navigating the challenges and opportunities of the entire device lifecycle. Beyond his professional roles, Axel is a passionate mentor and thought leader within the MedTech ecosystems in both the US and EU. He frequently delivers lectures and provides mentorship to startups and smaller companies, helping them navigate regulatory landscapes and accelerate business growth.
With his extensive expertise and practical insights, Axel is uniquely positioned to guide companies in achieving success across R&D, regulatory compliance, commercialization, and long-term business development.
