When a regulatory team moves its publishing and review system from an on-premise server to the cloud, the software is the easy part. What actually has to move is everything the old installation has accumulated: the way people sign in, the connections to document repositories, and — most importantly — every sequence the company has ever filed.
That filed history is the regulatory record. It has to arrive complete, and it has to be provably complete. And because filings do not stop for a migration, all of this has to happen while the old system keeps working.
Here is the approach we use when moving customers from dedicated installations to the DnXT cloud platform.
Run in parallel, change nothing destructive
Every step before cutover should be additive. The new environment is built and proven alongside the old one, and nothing is switched off, overwritten or redirected until users move. If any step would break the system people are using today, it waits.
Sign-in, side by side
Single sign-on is usually the first thing to prove, because nothing else can be tested by real users until it works. The safe pattern is to add the cloud environment to the company’s identity provider alongside the existing installation — a second credential, not a replacement — so both environments work during the transition. Then verify it end to end with a real user from the regulatory team.
Integrations from their new home
Document-repository integrations often have an address allowance on the provider’s side. Check whether the provider already allows the new environment’s address range before planning any change; sometimes, as in one recent migration, the integration works from the cloud with no code change on either side.
Copy both halves of the archive
A publishing installation typically holds two areas: a working area where documents are prepared, and an output area that holds what was published. Copy both. The output area is the filed record; the working area is what the team will need the next time they build a sequence.
Verify by bytes, not by counts
The easiest way to fool yourself in a migration is to compare file counts. Counts can match while content is missing, because listings often include folders as entries, and human-readable sizes do not add up reliably. Compare total bytes, from a machine-readable listing, on both sides.
Let the filed record settle disagreements
Older installations accumulate staged copies — a consultant’s working folder here, a duplicate there, sometimes with a typo in the application number in the folder name. When two copies disagree, do not trust the folder name. Open the filed regional backbone and read the application number it declares. That is the authority.
Cut over on notice, with training
Finally, agree the cutover with the regulatory team’s lead, not around them. Two weeks’ notice is a reasonable expectation, along with material that explains what changes for users: the new address, the new sign-in, anything that looks different. Users are provisioned against their identities in the company’s own directory, so their access follows them.
What you end up with
Done this way, the move to the cloud is uneventful by design. Sign-in and integrations are proven before anyone has to switch, the archive is verified complete, and the lifecycle of every application — every new, replace and delete operation ever filed — arrives intact.
Read how this worked in practice in our migration case study, or see our implementation services.
DnXT Solutions builds eCTD publishing, review and document management software and helps regulatory teams move to it. Talk to us about moving your submission history to the cloud.
