Electronic Batch Record Rollout: Sequencing Products and Lines Without Losing Control

Why Sequencing Decides the Outcome of an EBR Program

An electronic batch record (EBR) is the executed record of a batch captured in a computerized system rather than on paper. In most pharma and biotech plants it is delivered through a manufacturing execution system (MES), which guides the operator through each step, enforces the order of work, checks entries against limits, and records who did what and when. The regulatory basis for the record itself does not change when it moves from paper to screen. In the United States, 21 CFR 211.186 still requires a master production and control record for each product and batch size, and the executed record still has to follow it.² In the European Union, Chapter 4 of the EU GMP Guide still requires a batch processing record for each batch that is based on the currently approved manufacturing formula and processing instructions.¹

What does change is everything around the record: who writes the master, how it is approved, how operators interact with it, how quality reviews it, and how deviations are raised. When a site converts all of that for one product, the change is manageable. When it converts twenty products across six lines over three years, the order of conversion becomes the main source of risk.

The Question Every Program Faces Early

Eddie Ryan, writing for ISPE’s Pharmaceutical Engineering in 2024, framed the decision that every program faces: “Do we ‘go live’ as a ‘big bang’ or in phases, and if so, how do we approach phasing?”⁶ He also notes that the benefits of MES differ by manufacturing modality. Oral solid dose sites tend to value reductions in cycle time and documentation errors, while cell and gene therapy sites put more weight on contamination control and timely batch release.⁶ Both points matter for sequencing. The right first product for an oral solid dose plant may look very different from the right first product for a biologics or cell therapy site, because the benefit that justifies the program is different.

A full cutover of an entire site on one date is rare in regulated manufacturing, and for good reason. It concentrates all of the recipe authoring, validation, training, and review changes into a single window, and it leaves no fallback if something goes wrong in the first weeks. Almost every site therefore phases the rollout. The real question is how to phase it.

Two Ways to Phase, and Why the Labels Confuse People

ISPE’s GAMP Good Practice Guide on Manufacturing Execution Systems, first published in 2010, has a full appendix on developing an MES implementation strategy. Its table of contents lists separate sections on a horizontal implementation strategy, a vertical implementation strategy, phased deployment, and system controls during deployments.⁴ In practice, teams use these two labels in different ways, so it helps to describe the two options by what they do rather than by what they are called.

Neither option is wrong, and many programs combine them. A site might move weigh and dispense for all products first, because it is the step with the most transcription errors and the most repeatable logic, and then convert the remaining steps product by product. What matters is that the program writes down which approach it is using, because the answer changes how the hybrid period is controlled, which products share lines during the transition, and what an inspector will see if they pull a batch record in the middle of the rollout.

Choosing the First Product and Line

The first product matters more than any later one. It proves the system configuration, sets the pattern for master record design, trains the first group of operators and reviewers, and gives leadership its first evidence that the program works. Picking it well is worth several weeks of deliberate analysis.

Three Factors That Matter Most

Most sequencing decisions come down to three factors: how complex the product’s process is, how often it runs, and how ready its line is.

Process complexity. Complexity here means the number of steps, the number of calculations the operator performs by hand, the number of conditional branches (for example, “if the pH is above the limit, add buffer and recheck”), and the number of interfaces to equipment or other systems. The simplest product in the portfolio teaches the team very little. The most complex product exposes every weakness in the system at once. The best first product is usually in the middle: complex enough to exercise calculations, in-process checks, and at least one equipment interface, but not so complex that every batch creates a new question.

Batch frequency. A product that runs every week gives operators and reviewers repetition. By the end of the first month, the floor has executed the electronic record several times and the review team has closed several records. A product that runs twice a year gives almost no learning, and each campaign feels like a new go-live. Frequency also affects exposure. A high-volume product that runs every day moves a lot of material through a new system quickly, which raises the stakes of any configuration error. A product that runs every week or two is often the right balance for the first move.

Line readiness. A line is ready when its equipment is qualified and stable, its instruments can be connected (or the program has decided they will not be connected in this phase), its network and hardware at the point of use are in place, and it is not carrying a backlog of open deviations or pending equipment changes. A line with an open investigation into a recurring equipment fault is a poor place to introduce a new record system, because every new deviation will raise the question of whether the system or the equipment caused it.

Factors That Rule a Product Out, at Least for Now

Some conditions should move a product to a later phase regardless of its score on the three main factors:

• A pending regulatory event. A product facing a pre-approval inspection, a major variation or supplement, or a site transfer in the next several months should not also be changing its record system. Two large changes at once make both harder to control and harder to explain.
• A master record under active revision. If the paper master is about to change for process reasons, convert it after the process change is approved, not before. Otherwise the team converts the master twice.
• A product nearing discontinuation. Converting a product that will leave the portfolio within a year rarely returns the effort.
• Shared equipment with a product that will stay on paper for a long time. Mixed operation on one line is possible, but it creates a risk that operators confuse the two modes. More on this below.

A Simple Scoring Table

A scoring table does not make the decision, but it makes the reasoning visible to quality, operations, and IT at the same time, and it gives the steering group a record of why products were sequenced the way they were. The weights below are a starting point; each site should adjust them to its own priorities.

The reuse factor is the one most programs underweight. A first product whose unit operations (dispensing, granulation, blending, filling, and so on) are shared with many other products creates building blocks that make every later product faster. A first product with a unique process creates a master record that helps nobody else.

The Shared-Line Problem

Many plants run several products on one line. If product A moves to electronic records while product B stays on paper, the same operators will run a batch on screen on Monday and a batch on paper on Wednesday. That is manageable if the plan anticipates it, and risky if it does not. The main hazards are an operator following the paper habit of recording a value after the fact on an electronic batch, a supervisor signing a paper record for a step the electronic system already captured, and cleaning or line clearance records that exist in one system for one product and in the other system for the next.

Two practical answers help. The first is to sequence by line where the product mix allows it, so that all products on a given line move within a short window. The second, where that is not possible, is to make the mode of each batch unmistakable: a clear visual indicator at the start of the batch, separate paper forms that cannot be confused with the electronic workflow, and a supervisor check at batch start that confirms which record system governs the batch. These are small measures, and they prevent the most common transition deviations.

Master Batch Record Design Comes Before Configuration

The master batch record is the approved set of instructions for making a product at a given batch size. In US terms it is the master production and control record. Under 21 CFR 211.186(a), it must be prepared, dated, and signed by one person and independently checked, dated, and signed by a second person, and the regulation states the purpose of the requirement as “To assure uniformity from batch to batch”.² The same section lists what the master must contain, from the name and strength of the product to theoretical yields and complete manufacturing and control instructions.²

The regulation’s reference to a handwritten signature is sometimes raised as a barrier to electronic masters. It is not one. Under 21 CFR 11.1(c), FDA considers electronic signatures that meet Part 11 “to be equivalent to full handwritten signatures, initials, and other general signings as required by agency regulations,” unless a later regulation specifically excepts them.³ What matters is that the electronic approval workflow for the master meets Part 11 and that the two-person preparation and check are real, not a formality.

Why Paper on Glass Is a First Step, Not the End State

“Paper on glass” describes an electronic record that copies the layout and logic of the paper batch record onto a screen. Operators see the same pages and enter the same values, but on a tablet instead of a form. Ryan lists the choice between “paper on glass” and a fully integrated MES as one of the main strategic decisions that shape a program’s payback.⁶ Many sites use paper on glass as a first step, because it lets operators work through the familiar workflow on screen while the fuller electronic logic is built.

The appeal is speed. The master does not need to be redesigned, operators recognize the layout, and validation effort is lower. The limitation is that paper on glass carries over the weaknesses of the paper design. Manual calculations stay manual. Steps that should be blocked until a check passes are still open. Free-text fields that should be structured values stay free text. The result is a record that looks digital but does not prevent the errors that drove the program in the first place.

The sequencing implication is direct. If the program intends to move beyond paper on glass later, the product that goes first in paper-on-glass form will have to be converted a second time. That is sometimes the right choice, for example when the site needs to prove the platform quickly. But it should be a deliberate choice written into the plan, with the second conversion scheduled, rather than a default that nobody revisits.

Designing the Master for the Screen

A master designed for electronic execution differs from a paper master in several concrete ways:

• Every recorded value has a data type, a unit, and where relevant a limit. A weight is a number in kilograms with an acceptance range, not a blank line.
• Calculations move into the system. Yield, potency adjustment, and quantity to dispense are calculated from recorded inputs, and the formula is part of the validated configuration rather than a line on a worksheet.
• Order is enforced where order matters. The system prevents the operator from starting a step before its prerequisites are complete, such as line clearance, equipment status checks, and material verification.
• Branches are explicit. Conditional instructions become defined paths with their own recorded outcomes, instead of notes in a margin.
• Exceptions are designed in. The master defines what counts as an exception for each step (an out-of-limit entry, an override, a late entry, a skipped step), because those definitions later drive review by exception.

Chapter 4 of the EU GMP Guide sets the principle that governs this translation. It says that “The reproduction of working documents from master documents should not allow any error to be introduced through the reproduction process.”¹ For an electronic system, the working document is the executed batch record generated from the configured master. Testing that the executed record faithfully reproduces the approved master is therefore a core part of validating each product’s conversion, not a one-time platform test.

Build a Library, Not a Set of Masters

The ISA-88 series of standards on batch control gives the industry a shared set of models and terms for describing batch processes, including recipe models, and one part of the series is devoted to batch production records.⁵ Whether or not a site follows ISA-88 formally, its core idea is useful for sequencing: break the process into reusable procedural elements (operations and phases such as “dispense material,” “charge vessel,” or “perform in-process check”) and build each product’s master from those elements.

When the first product is designed this way, the elements it uses become a library. The second product that shares dispensing, charging, and in-process checks reuses those elements, already tested, and only the product-specific parameters and unique steps need new work. This is where the real speed in a rollout comes from. It is also why the reuse factor in the scoring table matters.

Recipe authoring is the step that most often determines the speed of the whole program. Emerson, a vendor of MES software, described the traditional conversion of paper batch records into MES recipes in a January 2026 announcement as a process of workshops, configuration, reviews, tests, and coding, and wrote that “These steps often take months and demand close collaboration between IT and operational technology teams.”⁷ That is a vendor’s description of a problem its own product is meant to solve, so it should be read in that light. But the underlying point matches what most programs find: authoring and approving the electronic master, not installing the software, determines how fast products can move.

Researchers have also started testing large language models to extract the structure of paper batch manufacturing records. A preprint posted to arXiv in November 2025 described a workflow that converted three real batch manufacturing records of 15 to 66 pages into structured data, with composite confidence scores in the low to high eighties, and presented the method as a way to support human-in-the-loop digitization rather than as a replacement for expert review.¹³ This is early, unreviewed work on a small sample. It may help teams inventory and structure legacy masters faster, but any extracted content still has to go through the same two-person preparation and check that the regulation requires.

What Inspectors Find in Master Records

Dennis Cantellops, writing in Pharmaceutical Technology in May 2026, describes an evaluation of approximately 80 inspections across manufacturers of sterile and nonsterile drug products, biotechnology products, APIs, and finished drug products.⁸ The recurring master record problems he summarizes include uncontrolled page changes, omitted critical process parameters, incorrect theoretical yields, missing environmental or storage limits, and weak deviation histories.⁸ Every one of those is easier to prevent in a well-designed electronic master than on paper. Page changes cannot happen outside the approval workflow, parameters can be made mandatory, and theoretical yield can be calculated and checked by the system. But every one of them can also be carried straight into the electronic master if the team converts the paper document without reviewing it first. Conversion is the best opportunity a site will have to fix its masters, and the rollout plan should budget time for that review.

Parallel Running and the Hybrid Period

Every rollout has a period when some records are electronic and some are on paper. For a function-first program, that period can last years at the product level. For a product-first program, it can be short for each product but still long for the site as a whole. How the site controls this period is the part of the rollout most likely to draw questions from an inspector.

What the Rules Say About Hybrid Records

EU GMP Chapter 4 addresses the situation directly. Clause 4.1 recognizes that “Many documents (instructions and/or records) may exist in hybrid forms, i.e. some elements as electronic and others as paper based,” and states that “Relationships and control measures for master documents, official copies, data handling and records need to be stated for both hybrid and homogenous systems.”¹ The same clause calls for appropriate controls for electronic templates, forms, and master documents, and for controls that protect the integrity of the record throughout the retention period.¹

Cantellops makes the practical point in plain terms: hybrid systems, which combine electronic templates with paper execution, “are commonly used in industry; however, they may introduce additional complexity in document control and data management.”⁸ The requirement is not to avoid hybrid states. It is to define them in writing, before they start.

Three Different Things Called “Parallel Running”

Teams use “parallel running” for three different activities, and mixing them up causes problems.

EY’s Austin Amery notes that moving from a paper master batch record to an EBR “can take several iterations of prototyping demonstrations and dry runs.”¹⁰ That is the most useful form of parallel running: iterative dry runs in a non-GMP environment that improve the design before the first production batch. It is also the form that creates no record conflict.

Defining the Official Record for Every Batch

The simplest control for the hybrid period is a written rule, in the site’s documentation procedure, that states for each product and each step which record is official on which date. A table in the procedure (or a controlled list referenced by it) should show, for each product: the date the electronic master became effective, the date the paper master was retired, any steps still recorded on paper and the form numbers used, and how paper elements are linked to the electronic record. When an inspector asks “which record is the original for this batch?”, the answer should come from that table in seconds.

Where paper elements remain, such as a manual cleaning log or a printout from an unconnected instrument, the link between the paper and the electronic record has to be controlled. A scanned copy attached to the electronic record is only useful if the scanning process produces a verified true copy and the paper original is retained or disposed of under procedure. Many sites find that it is easier to leave a short list of paper steps in place until the relevant instrument or log is connected than to create an elaborate scanning process that has to be validated and maintained.

Exit Criteria for the Hybrid Period

Exit criteria matter because, without them, products stay in transition indefinitely. Paper forms remain on the floor “just in case,” shadow recording continues because nobody formally ended it, and the site drifts into a permanent hybrid state that is harder to control than either paper or electronic records alone.

Turning On Review by Exception One Product at a Time

Review by exception is often the benefit that justifies the whole program. In plain terms, the system screens the executed record and presents only the exceptions (out-of-limit values, overrides, late entries, skipped or repeated steps) for human review, instead of asking a reviewer to read every page. EY’s Amery describes the scale of the benefit: “Through a successful RBE implementation, one could reduce a 150-page batch record review to a three-page exception report with key exceptions highlighted.”¹⁰

The prerequisites for review by exception (defined critical parameters with machine-checkable limits, validated exception logic, a documented rationale for what does not need review) are covered in depth elsewhere on this site. The rollout question is different: when, for each product, should the site move from full review of the electronic record to review by exception?

Why Review by Exception Should Not Start at Go-Live

Exception rules are product-specific. They depend on the parameters, limits, and branches in that product’s master. On the day a product goes live, the site has no evidence that those rules catch everything a full review would catch. It also has no baseline for how many exceptions a normal batch generates. Starting review by exception on day one means trusting logic that has been tested in validation but never checked against real production batches.

A safer pattern is to run full review of the electronic record for an initial set of batches while also generating the exception report, and then compare the two. For each batch, the reviewer notes every issue found in the full review and checks whether the exception report flagged it. When a defined number of batches show that the exception report caught every issue the full review found, and the reasons for any gaps have been fixed and retested, the product can move to review by exception under change control.

ISPE’s MES guide reflects this staged thinking. Its review by exception appendix includes sections on considerations for new or upgraded systems, phased deployment, and periodic reassessment of the system.⁴

The Exception Rate as an Early Warning

The number of exceptions per batch tells the program a great deal in the first weeks. A very high rate usually means the limits in the master are too tight, the workflow does not match how the floor works, or operators have not yet learned the system. A rate of zero on a complex product is also a warning sign, because it may mean the exception logic is not firing. Amery notes that higher comfort with the electronic system reduces the likelihood of unnecessary process exceptions.¹⁰ Tracking the rate by product and by shift during transition separates training problems from design problems.

Where This Leads

BioPhorum announced its Batch Disposition Manifesto in a February 2026 news item, which says the manifesto is aimed at regulators, standards bodies, technology providers, manufacturers, and quality professionals. BioPhorum describes it as “not a prescriptive guide, but rather a collaborative tool to help you reflect on your current processes and consider pathways toward digitization and advanced maturity.”¹¹ Writing about the manifesto for MasterControl’s GxP Lifeline, Jake Ure notes that the target state “IS NOT about eliminating quality oversight or ‘auto-releasing’ product.”¹² Ure also describes a staged model that MasterControl discusses with its customers, in which the middle stage is “All product lines are paperless, review by exception is crisp, and only true exceptions are reported.”¹² He adds that many organizations will run mixed release models for years, using real-time release where the risk profile and product allow and traditional release elsewhere.¹²

The same pattern holds one level down, for the records themselves, and it is worth keeping in mind for any steering committee. A site running paper and electronic records side by side for several years, while products move one at a time, is common. What is not acceptable is a hybrid state at the product level that nobody has defined, measured, or planned to end.

Training for the Transition, Not Just the System

Training for an electronic batch record rollout is usually planned as system training: how to log in, how to navigate, how to sign, how to raise an exception. That training is necessary but not enough. The harder skills are the ones specific to the transition period: knowing which mode a batch is in, knowing what to do when the system and the paper habit disagree, and knowing how to use the contingency procedure without improvising.

Amery puts it plainly: “The execution of a well-designed EBR is only as successful as the training provided to the end user prior to go-live.”¹⁰ Tim Sandle, writing in Outsourced Pharma, makes a related point, that “attention also needs to be paid to staff training to ensure acceptance of a different way of working.”⁹ ISPE’s MES guide devotes an appendix to human and workflow considerations, including enforced operational sequences, psychological and cultural aspects, and user interface design.⁴

Train by Role, and Train Close to Go-Live

Different roles need different content:

Timing matters as much as content. Training delivered three months before go-live fades. Training delivered in the two to three weeks before the first production batch, with practice on the actual product in a training environment, carries into the first batches. For products that run infrequently, a short refresher before each campaign during the transition period prevents the first batch of each campaign from becoming a relearning exercise.

Super Users on Every Shift

The most useful single measure in the first weeks is a trained super user on every shift that runs a product in transition. This is an operator or lead with deeper training who can answer questions at the point of use, spot mode errors, and route real system problems to support quickly. Programs that concentrate their experts on day shift find that night and weekend shifts generate a disproportionate share of transition deviations.

Proficiency, Not Signatures

A training record that shows an operator read the procedure does not show that the operator can run the batch. For a new record system, the evidence that matters is observed execution of a realistic simulated batch. That evidence also protects the site if an early deviation is investigated, because it shows that the operator was trained on the task, not just on the document.

Keeping Control While the Documentation System Changes

Sandle’s advice applies to the whole rollout, not just the design phase: “data integrity considerations need to be at the forefront of any electronic batch record implementation exercise and part of the everyday use of such systems.”⁹ During a rollout, keeping control means three things: controlling changes to masters in both systems, recognizing and classifying transition-related deviations, and watching a small set of measures that show whether the rollout is creating risk.

Change Control for Two Masters at Once

From the moment conversion of a product’s master starts until the paper master is retired, the product has two masters in some form: the approved paper master governing production, and the electronic master under development or in validation. Any process change approved during that window has to reach both. The cleanest approach is a short change freeze on the paper master once conversion starts, with an exception route for urgent changes that requires the electronic master to be updated and retested in the same change record. Without that rule, the electronic master can go live one or two revisions behind the paper master, and the first batches on the system are made to outdated instructions.

The ISPE MES guide lists operational change control and configuration management among its core operation-phase topics, and devotes an appendix to configuration management, including functional and product configuration and coordinated release processes.⁴ For a rollout, the practical point is that the electronic master is part of the validated configuration of the system, and changes to it follow the same change control discipline as changes to the software, with a clear owner for the product content.

Classifying Transition Deviations

Deviations in the first weeks of a product’s electronic life tend to fall into a few groups: master design errors (a wrong limit, a missing step), configuration errors (a calculation implemented incorrectly), usability or training problems (an operator entering a value in the wrong field), infrastructure problems (a tablet or network outage), and ordinary process deviations that would have happened on paper too. Tagging each deviation with a transition category, in addition to its normal classification, lets the program see patterns quickly. Five usability deviations on one step point to a screen design issue that retraining will not fix. Three configuration errors in one week point to a gap in testing that affects the next product as well.

A Small Set of Transition Measures

The last measure is the most important for sequencing. Every product in transition draws on the same small group of recipe authors, validation staff, super users, and quality reviewers. When too many products are in transition at once, the controls described in this article start to slip, not because anyone decided to relax them, but because the people who apply them are spread across too many products. Setting a hard limit on concurrent transitions (for many sites, two or three products at a time) is one of the most effective controls a steering group can put in place.

Stop and Hold Criteria

A rollout plan should also say when to pause. Reasonable triggers include a critical deviation attributed to the system or the master, a data integrity finding in an internal audit, a validation gap discovered after go-live, or a sustained rise in transition deviations across products. Pausing the next product’s go-live while the cause is fixed is far easier than carrying the same defect into three more products. A pause is not a failure of the program. It is evidence that the program’s controls work.

Historical Records Stay in Their Original System

Historical batches executed on paper remain paper records and must be retained and retrievable for their full retention period. Most sites do not migrate historical paper batch records into the new system, and there is rarely a reason to. The ISPE MES guide treats data migration as a distinct project-phase topic, along with record retention, archive, and retrieval in the operation phase.⁴ For a rollout, the practical questions are narrower: where investigators will look for the history of a product that spans both systems, how annual product reviews will combine paper and electronic data for the transition year, and how genealogy links will work for materials that cross the boundary. Answering those questions before the first go-live saves significant effort in the first investigation or product review that spans the change.

A Deployment Plan That Holds Across the Portfolio

Pulling these threads together, a rollout plan that keeps control across a full portfolio usually follows a pattern like the one below. The durations will vary widely by site, platform, and product mix, so the plan is expressed in steps and gates rather than weeks.

What Goes Wrong When the Plan Is Skipped

The Role of the Steering Group

The steering group for an electronic batch record rollout should include the site head of quality, the head of operations, the MES product owner, and the validation lead, at a minimum. Its most important decisions are not about the software. They are about the sequence of products, the limit on concurrent transitions, whether a given product has met its exit criteria, and whether to pause. Those decisions need people who can weigh production commitments against quality risk and who have the authority to move a go-live date when the evidence says it should move.

The steering group also has a communication job. Operations teams outside the current phase need to know when their products will move and what will be asked of them. Quality reviewers need to know when their review workload will change. Regulatory affairs needs to know when products that are subject to upcoming filings or inspections will be on which system. A published, regularly updated sequence, with the reasoning behind it, prevents much of the friction that surrounds these programs.

Conclusion

An electronic batch record rollout succeeds or struggles on its sequence. The software, the validation package, and the business case all matter, but the day-to-day risk comes from the period when a site runs two record systems at once, and the order in which products and lines move determines how long that period lasts and how hard it is to control. Choosing a first product of moderate complexity, steady frequency, and a ready line; redesigning masters for the screen from reusable elements; defining the hybrid state in writing; earning review by exception product by product; training for the transition itself; and limiting how many products are in transition at once are the practices that keep a site in control while its documentation system changes. None of them is complicated. Each of them is easy to skip under schedule pressure, which is why they belong in the plan from the start.

Sakara Digital works with pharma and biotech organizations planning and running manufacturing digitization programs, including electronic batch record and MES rollouts. If you are sequencing a rollout across products, lines, or sites and want an independent view on the order, the controls, or the readiness criteria, we are happy to have that conversation.

For Further Reading