How to Move a Client from Manual Files to a Controlled ePSMF
The migration tracker looks complete.
Every SOP has a destination. The product list has been uploaded. The current PSMF sections are visible in the new platform.
Then a reviewer asks:
"Who changed this vendor information in March, and what was approved at that time?"
The new ePSMF contains the latest information, but the manual file does not show who made the earlier edit. The electronic system cannot create an audit trail for an action that occurred before it existed.
That is where a clean-looking migration can become an inspection risk.
Moving a client from manual files to a controlled electronic PSMF is not a document-conversion exercise. It is a handover of content, evidence, responsibilities, and change control. The receiving team must establish where the legacy record ends, where the new electronic history begins, and how the organisation verified the transition between them.
Key Takeaways: A reliable PSMF handover starts with an approved legacy baseline and a clear boundary between the old and new systems. Current content, historical records, unresolved discrepancies, and missing evidence should be handled separately. The ePSMF should become the controlled master only after reconciliation, workflow testing, access checks, training, QPPV approval, and inspection-output rehearsal.
Start by Defining the Boundary Between the Two Systems
A migration often fails because teams treat go-live as one moment.
In practice, three different control points are needed.
The legacy freeze date establishes the approved manual PSMF that will serve as the migration baseline. From that date, the baseline should no longer be edited. Its version, approval status, location, open changes, and pending annex updates should be formally recorded.
The migration verification date confirms that the transferred content has been checked against the frozen baseline and, where necessary, against the authoritative source systems. By this stage, discrepancies should have been documented and assigned for resolution.
The ePSMF effective date is the formal point at which the approved electronic file becomes the controlled master. It should not be declared until the organisation has completed reconciliation, access testing, workflow testing, training, QPPV review, and output verification.
The pharmacovigilance system will continue changing between the freeze and effective dates. A vendor may change, a product may be authorised, or a procedure may be revised during the migration. These interim changes need a controlled register so they are either incorporated before go-live or transferred into the new review workflow.
Understand the Legacy PSMF Before Restructuring It
The receiving team should first establish what the client currently considers to be the controlled PSMF.
That review should cover the approved main body, annexes, historical versions, Annex I records, QPPV documentation, product lists, procedures, contracts, audit records, CAPAs, computerised-system information, review comments, and approval evidence.
Where the client maintains more than one PSMF, the migration scope must identify which pharmacovigilance system each file describes. If global and local PSMFs are involved, the team should also determine which information is shared centrally and which content remains territory-specific. A structured global and local PSMF management model can help preserve that distinction without recreating isolated country files.
Every legacy record should then receive one of four decisions.
Migrate: Current, approved, and applicable information moves into the active ePSMF after verification.
Archive: Superseded PSMF versions, historical annexes, and earlier approval records remain available in a controlled, read-only archive.
Remediate: Incomplete or inconsistent information enters a documented resolution process before it becomes active content.
Replace: Manual process controls, such as email approvals, colour-coded trackers, and folder naming conventions, are replaced by the configured electronic workflow. Their historical evidence may still need to be retained, but the manual control itself should not be reproduced inside the new system.
GVP Module II allows frequently updated annex information to be generated from controlled systems and permits superseded annex content to be held outside the active PSMF, provided the history remains maintained and available to authorities.(European Medicines Agency (EMA))
Do Not Manufacture a Legacy Audit Trail
This is the most important rule in the handover.
A system-generated audit trail begins when users start performing actions inside the electronic platform. It cannot truthfully prove who edited a spreadsheet or Word document several months earlier if the manual process never captured that information.
Where historical evidence exists, preserve it in its original form.
Where it does not exist, the organisation should document the limitation, identify the affected content, assess its impact, reconcile the current information against an authoritative source, and record the remediation and approval.
The migration itself should receive a clear Annex I entry explaining the source system, scope, cutover date, verification performed, known historical limitations, responsible reviewer, and approval of the new controlled state.
PSMF Manager's Ask AI capability may suggest wording for that Annex I entry, but it should not infer missing facts or manufacture evidence. The responsible user must review, edit, and approve the suggested text.
Historical versions created after go-live should then be preserved through the platform's version history and audit trails. The electronic history should begin honestly from the effective date, while the earlier manual record remains available through the legacy archive.
Reconcile the PSMF Against the Current Operating System
The frozen legacy file proves what the client previously approved. It does not automatically prove that every record remains correct on the migration date.
Before final approval, the receiving team should compare high-impact information against the current source.
QPPV identity, contact information, operating location, and delegation records should align with the applicable organisational records. Product and territory information should match the controlled regulatory source. Vendor responsibilities should reflect current agreements. Procedure references should point to active versions. Audit and CAPA information should reflect present status rather than the status at the last scheduled PSMF review.
Corrections identified during this exercise should not be inserted silently into the migrated file. They should move through a visible review process showing what changed, why it changed, who proposed the correction, and who approved it. The tracked-changes workflow supports visual change review, attribution, comments, and approval activity within the affected content.
Where source information is held in compatible repositories or systems, external data-source integration can later help bring new source changes into the PSMF workflow. The initial migration load should still be independently reconciled. A successful connection proves that data moved, not that the information was complete, accurate, or applicable.
Validate the Configured Process, Not Only the Software
The platform vendor may provide documentation and testing evidence for the standard application. The regulated organisation must still demonstrate that its configured workflow performs its intended use.
The validation strategy should reflect how the platform has been configured, whether integrations are present, how access is assigned, and which electronic records or approvals are being relied upon.
EU GMP Annex 11 provides relevant principles for computerised-system control. It states that when data are transferred to a new format or system, validation should confirm that their value and meaning have not changed. It also expects user requirements to remain traceable, access to be restricted and recorded, backup restoration to be tested, and system-generated audit trails to remain available in an intelligible form.
For the handover, this means testing the actual configured process.
The team should confirm that dates, identifiers, and text have retained their meaning during transfer. Current and historical records must remain clearly distinguishable. Authors, reviewers, approvers, QPPVs, administrators, vendors, and local users should receive only the access required for their responsibilities. Audit trails should identify who performed an action and when. Previous approved versions should remain retrievable, and backup and recovery testing should demonstrate that records remain readable and complete.
The organisation should assess PSMF Manager's compliance and security controls against its own intended use and quality requirements. The platform describes role-based access, two-factor authentication, encryption, automated backups, version control, and detailed audit logs.
Where electronic records or signatures are used to satisfy FDA requirements, the applicability of 21 CFR Part 11 should be assessed separately rather than assumed solely because the system is electronic.
Make the Cutover a Demonstration of Control
The migration should not end with a content count or a successful login.
Before the ePSMF effective date, the receiving team should take one real discrepancy identified during migration and trace it through the full process:
Source discrepancy → impact assessment → proposed correction → review → approval → controlled version
This demonstrates that the configured workflow controls the change, not only the final output.
The organisation should then rehearse a PSMF request using a defined data-lock date. Someone outside the migration team should be able to identify the approved version, generate the complete document, locate the approval, retrieve the previous state, explain the migration entry in Annex I, and trace selected product and vendor records back to their sources.
Under EU GVP Module II, a requested PSMF must be provided within seven days, and immediate access may also be required at the stated PSMF or QPPV location. Other jurisdictions may apply different timelines, so the relevant local requirement should be confirmed for every file in scope.
The PSMF generation workflow should therefore be tested using the actual migrated file before go-live. The platform generates a read-only PDF from approved content and can include the section and annex structure, bookmarks, and Annex I information. If the exercise depends on guidance from the implementation team, the handover is not yet complete.
Watch What Happens After Go-Live
The first post-go-live review is where the organisation learns whether the new control model is working in practice.
Users may return to email approvals, offline spreadsheets, or local document copies because those methods feel familiar. Notifications may be routed to the wrong owners. Open legacy changes may not have entered the new workflow. Access rights may no longer match current responsibilities.
An early review should therefore examine actual user behaviour, not only technical performance.
It should confirm that new changes are being initiated inside the ePSMF, reviews and approvals are traceable, source updates are reaching the correct owners, and the frozen legacy file is no longer operating as a parallel master.
Procedures should also reflect the new responsibilities and electronic workflow. Training should cover what each role is expected to do inside the system, how changes are escalated, and how Annex I information is reviewed. A passive acknowledgement of a revised SOP is less useful than confirming that users can perform their assigned workflow correctly.
What the Final Handover Evidence Should Prove
A complete migration record should allow an independent reviewer to understand how the controlled electronic state was established.
It should show which legacy version formed the baseline, what information was migrated, which records remained archived, which discrepancies were identified, how they were resolved, how the configured workflow was tested, who approved the result, and when the ePSMF became effective.
The organisation should also be able to locate the validation evidence, training records, migration report, Annex I migration entry, approval record, inspection rehearsal output, and legacy archive location without relying on the memory of the implementation team.
The purpose is not to create another large handover binder.
It is to ensure that continuity can be demonstrated after the people who managed the migration have moved on to other work.
A Digital PSMF Is Only as Reliable as the Transition Behind It
An ePSMF migration is complete when the organisation can explain the boundary between the old system and the new one.
It should be able to show what was preserved, what was corrected, what could not be reconstructed, who verified the migrated state, and how every future change will be controlled.
A digital platform cannot repair an uncertain legacy history simply by importing it.
It can provide a clear, traceable, and defensible control process from the effective date forward.
Review the complete PSMF Manager feature set or request a demonstration to assess how global and local file control, tracked changes, version history, source connections, Annex I support, and PSMF generation can support an ePSMF handover. Request a demo