Your Veeva Programme Has a Project Plan. Does It Have an Architecture?

The client-side decisions that should be settled before configuration begins, and the delivery consequences when they remain unowned.

In my experience, a fixed-scope Veeva programme often begins with a statement of work agreed before discovery is complete. This is commercial reality. The work needs to be priced before the estate, data and operating constraints are fully understood.

When an architectural question arises during build and nobody on the client side owns the answer, it is usually answered by the consultant closest to the configuration. That consultant may be capable and acting in good faith. The decision is still being made inside the delivery constraints of the statement of work.

The vacancy creates the outcome.

Configuration is not architecture. Architecture records why the quality system has been translated into Vault in a particular way, how the design holds together across workstreams, and who owns the consequences after the programme team leaves.

Seven decisions expose the gap most clearly.

1. Data Migration Ownership

Migration statements of work are commonly expressed as technical activities: extract, transform, load and reconcile. A competent migration team can execute all four. The quality organisation still has to decide what each class of legacy record should become in Vault.

Which records arrive as structured data and which arrive as documents? Does a deviation closed in 2019 need its full approval history in Vault, or is an approved rendition sufficient? What happens to records that remain open under a legacy process with no direct equivalent in the target design? Which information stays in a validated archive, and how will a user retrieve it alongside the Vault record?

The hardest category is usually the record that fits no clean mapping rule.

On an enterprise Vault migration of more than one million legacy records that I worked, the main mapping rules were settled relatively quickly. The exception categories took considerably longer. Each category needed a documented position explaining how those records would be represented, retained and retrieved. Quality had to approve that position before load.

That approval matters because the implementation partner will not normally be present when a migrated record is examined years later. The site Quality team will need to explain what was transformed, what was retained, and why the record remains a faithful representation of the source.

Use difficult records during design. Include an open CAPA with overdue actions, a deviation linked to several batches, a supplier with multiple manufacturing sites, a record containing obsolete reference data and an event whose audit trail affects its interpretation. Clean examples test the loader. Exceptions test the architecture.

Design test: Pick a difficult migrated record and ask the team to open it. Walk through every transformation and retained artefact, reconcile it to source, and show how it will be used during operation and inspection.

Record counts and checksum matches establish whether expected files and rows arrived unchanged. Semantic reconciliation goes further. It checks whether the migrated record still means the same thing, whether its relationships remain intelligible, and whether authorised users can retrieve it in the context of the quality process.

2. Validation and Release Strategy

Vault is vendor managed and changes on a scheduled release cadence. The current effective EU GMP Annex 11 requires computerised systems to remain in a validated state through controlled change and periodic evaluation. GAMP 5 Second Edition provides the risk-based lifecycle guidance commonly used to put those expectations into practice.

The question for a Vault programme is specific: can the organisation produce an accurate statement of what is deployed in production, what changed, why it changed and who approved it?

Change tickets, configuration workbooks, test evidence, deployment logs and approval records may all exist. The control weakens when they cannot be connected to the production configuration without reconstruction by the people who have been on the platform longest.

In a separate enterprise platform governance role, I used Veeva Metadata Definition Language, or MDL, with GitHub to place supported configuration definitions under version control. Proposed changes were reviewed before promotion. The repository preserved a timestamped difference between approved versions and provided a reliable configuration history.

The repository review was one part of the evidence. A controlled release still required an approved change, impact and risk assessment, suitable testing, segregation of duties, deployment evidence and post-deployment verification. The configuration history linked those records to the components that actually changed.

There are practical limits. Not every Vault component or dependency is represented and deployed in the same way. Configuration migration packages have component, dependency and deployment-order considerations. Some security overrides and relationships need specific treatment. The release process must identify which elements sit inside the version-controlled path and how the remaining elements are governed.

This baseline improves release assessment. When Veeva issues a release, the client can compare the release impact against its intended use and known configuration footprint. The team can then identify affected controls, regression scope, procedural changes and any post-release checks. Without a trusted baseline, impact assessment begins with discovering the system again.

Validation also needs visible ownership and resourcing in the statement of work. I have seen it consume a material share of GxP delivery effort. If it is absent as a separately planned workstream, the client should establish who is producing the evidence, what supplier material will be assessed and reused, and which activities remain the client's responsibility.

At the time of writing, the January 2011 Annex 11 remains the effective text listed in EudraLex Volume 4. The European Commission and PIC/S published a revised draft on 7 July 2025, alongside a revised Chapter 4 and a new Annex 22 on artificial intelligence. Consultation closed on 7 October 2025. The revised text strengthens lifecycle management, supplier and service provider oversight, requirements definition, data integrity, audit trails, electronic signatures and system security. Until the final version is adopted, it indicates direction rather than obligation, and any programme designing to it should be explicit about which it is doing.

Design test: Choose one critical control changed in the last release. Can the team move from production configuration to the approved change, risk assessment, test evidence, deployment record and verification without relying on personal memory?

3. Operational Ownership After Go-Live

Every implementation plan includes hypercare. Fewer define the operating state that hypercare is expected to establish.

The central decision is the boundary between the internal platform team and external support. What may an internal administrator change? Which changes require architecture, Quality or validation review? Which activities remain with the implementation or managed-service partner? Who approved that division?

A narrow boundary may suit an organisation with limited internal capability. The internal team might maintain users, reference data and selected picklists while external specialists manage lifecycle, workflow and security changes. A wider boundary can work where the organisation has invested in experienced administrators, architecture oversight and validation capability.

An undefined boundary is the expensive option. The internal team discovers its limits when a business change is already waiting. The original partner may then become the only practical route to delivery, even though long-term support was never budgeted or competed.

Write the boundary during design. Name the decision rights on each side. Attach a capability-transfer plan to every responsibility moving in-house. That plan should include supervised execution, independent execution and evidence that the internal team can operate the governed process.

Set the hypercare exit gate against capability rather than elapsed time. Thirty days on the calendar establish only that thirty days have passed.

The same principle applies to release assessment, security changes, integration failures and inspection retrieval. Procedures and training records help. The future team should also perform the work before the programme demobilises.

Design test: Before the partner demobilises, give the internal administrator a real configuration change and step back. Can they take it from impact assessment through approval, test, deployment and verification without a partner resource anywhere in the chain? If the answer needs a caveat, the boundary has not been established.

4. Vault and Application Boundaries

The placement of Quality, RIM, Clinical and connected services shapes the data model, security, reporting and future integrations. These boundaries may be influenced early by licensing and deployment decisions, then treated as fixed architecture.

Record the reasoning while change is still practical. State which application owns each critical data element and event. “Supplier data comes from SAP” is too broad when SAP owns the legal entity, Vault owns qualification status and another system owns manufacturing-site data. Revisit the boundary before adding the next application or connection.

5. Security and External-User Access

Contract manufacturers, suppliers and other external parties usually need a controlled subset of quality records. An internal access model rarely extends outward without additional design.

Decide the external pattern before configuration hardens. Define what an external user can view, change and infer through related records, reports and searches. Test complete personas against Dynamic Access Control, sharing rules, permission sets, field-level security and Atomic Security. Also name the owner of the user-role data on which dynamic access depends.

6. Integration Dependencies

The primary delivery risk is often organisational. An ERP, LIMS or identity team may learn about the dependency after its own roadmap is committed.

Obtain named ownership and written delivery commitments before the Veeva plan assumes the interface. For each critical flow, define failure detection, business impact assessment, reconciliation, recovery and retained evidence. If an interface creates a quality event or supplies data used in a regulated decision, its failure belongs in the quality operating model as well as the support queue.

7. Global Versus Local Process Design

Set the acceptance criteria for local variation before site engagement begins. Core statuses, critical classifications and enterprise reporting fields may require global consistency. Local regulatory steps, language, notification paths and role assignments may justify controlled variation.

Each exception should have an owner, rationale, affected sites and review condition. This turns approval or refusal into a governed design decision. It also prevents a global template from accumulating one-off states, object types and classifications that fragment reporting and increase release effort.

Closing

Some readers will argue that this is precisely what the implementation partner is being paid for. On a well-run programme with a strong architect embedded on the client side of the relationship, that can be true. My position is that it should not depend on getting lucky with who is assigned.

These seven decisions do not have universal answers. They depend on the legacy estate, regulated processes, site footprint, implementation scope and internal capability. That is why each needs a named client-side owner with authority across workstreams.

To test this on your own programme, take the seven headings above into your next steering meeting and ask for a name against each one. Not a workstream. Not a document. A person who can make the decision and defend it eighteen months from now.

Most programmes I have seen can answer three or four immediately. The gaps tend to be migration exceptions, release governance and the post-go-live boundary, and they tend to be gaps because nobody has been asked.