How to Use ChatGPT to Draft ERP UAT Scripts and Cutover Runbooks

The short answer: Describe each business process to ChatGPT in your own words and ask for UAT scripts with preconditions, steps, expected results and the negative cases people skip — then have it turn your cutover sequence into a runbook with owners, timings, go/no-go gates and rollback triggers. It drafts the paperwork in hours. It cannot own the decision or be in the building at 06:00 on cutover Sunday.

Six weeks before an ERP go-live, the documentation position is usually the same at every mid-market company. There is a project plan, there is a partner's standard template, and there is a shared drive containing three half-finished test scripts written by whoever had a quiet Tuesday. The functional consultants are configuring. The business users who know how orders actually flow are doing their day jobs. And someone has just asked who is writing the cutover runbook.

The work is not intellectually hard. It is voluminous, tedious, and requires precisely the people who have no time. That combination is why it is always late and always thinner than it should be — and why it is exactly the kind of drafting a language model does well.

What follows assumes you keep the judgement. The model writes the first version of the paperwork; your people decide whether it is right, and your people run the weekend.

Why Go-Live Documentation Is Always Late and Always Thin

Four reasons, and naming them helps you plan around them.

It competes with configuration. Until the system is configured you cannot fully test it, so writing test scripts feels premature — and by the time configuration is done, the go-live date is close and everything is urgent.

It requires business knowledge, not system knowledge. The consultant knows the module; only your credit controller knows what happens when a customer exceeds their limit mid-order. Extracting that into written steps takes their time, which is the scarcest resource in the project.

The negative cases get skipped. Everyone writes the happy path. Nobody writes the test for a partial delivery, a credit note against a closed period, or a customer with two active price agreements — which is where go-lives actually break.

The runbook is treated as a checklist rather than a sequence. A list of tasks is not a cutover plan. A cutover plan has an order, dependencies, timings, named owners, and defined points where you decide whether to continue.

What ChatGPT Can Draft From a Process Description

The input is not your ERP. It is your description of how the business works, in plain language, written by the person who knows.

How Do You Get UAT Scripts Worth Running?

Describe one process end to end — where it starts, who touches it, what the system should do, what the exceptions are. Then ask for test scripts in a fixed structure: test ID, process area, precondition, roles involved, numbered steps, expected result, and a pass/fail field.

Two instructions make the difference between generic scripts and useful ones.

Ask explicitly for negative and edge cases. "Generate the failure paths a first-time implementer would forget" produces the partial-shipment case, the backdated invoice, the tax-code exception, the approval limit boundary. You will discard some as inapplicable; the ones you keep are the ones that would otherwise have surfaced in week one of live operation.

Ask it to list the assumptions it made. A model filling gaps silently is a liability. A model that ends with "I assumed three-way matching is enforced and that credit limits block rather than warn" hands you a review list, and those assumptions are often the questions your project should have answered already.

Keep data out of it. Describe that an order has a customer, a price agreement and a delivery date; do not paste your actual customer master. Test scripts need shapes, not records.

How Do You Turn a Cutover Plan Into a Runbook?

Give it your intended sequence at a high level — final backup, freeze transactions in the legacy system, extract balances, load master data, load open items, reconcile, validate, open the new system — plus the roles you have available and the window you have to work in.

Ask for a runbook table rendered as a numbered list: step, owner role, start time, duration, dependency, verification check, and rollback trigger. The last two fields are the ones that get left out of hand-written runbooks and the ones that matter at 04:00.

Then ask the harder question: "Where in this sequence is the last point at which we can still abort cleanly?" That is your go/no-go gate, and having a model propose it gives your project manager something concrete to argue with rather than a blank page. The same "draft the structure, then have humans correct it" pattern works for generating SOPs and onboarding documentation, and the correction step is what makes both of them safe.

A Worked Example — One Order-to-Cash Process Turned Into Scripts and a Cutover Slot

A 350-person distributor is moving to a new ERP with a three-day weekend cutover. The finance systems lead describes order-to-cash in about 600 words: order capture from EDI and email, credit check, allocation from two warehouses, partial shipments allowed, invoice on despatch, payment terms varying by customer group, credit notes for short deliveries.

From that description, one pass produces roughly 25 UAT scripts covering standard order flow, credit-limit breach, partial shipment and back-order, price agreement precedence, and the credit-note path — with the model noting five assumptions it had to make. Three of those assumptions turn out to be wrong, which is a finding rather than a failure: it takes twenty minutes to correct and it surfaced a genuine gap in how the project had specified allocation rules.

The business user's review is where the real value appears. Reading 25 drafted scripts and correcting them takes a fraction of the time writing them from scratch would have, and reading is a task a busy person will actually do at 5pm. Two scripts get deleted as inapplicable, six get materially rewritten, and four new ones get added for cases only the credit controller knew about.

The cutover slot is drafted the same way. The sequence becomes 40 numbered steps across the weekend, each with an owner role, a duration, a verification check and a rollback trigger — plus a proposed go/no-go gate on Saturday at 14:00, after balances are loaded and reconciled but before the first live transaction. The project manager moves the gate two hours earlier for a reason the model could not have known: the finance director flies out Sunday morning.

What the exercise produced is not a finished plan. It is a complete first draft, produced in a day, that the people who matter can react to — which is a fundamentally different problem from producing it from nothing.

AI-Drafted Go-Live Documentation vs Partner Templates vs Starting Blank

• Fit to your actual business — AI drafting wins. A partner template describes a generic order-to-cash process; a description you wrote describes yours.
• Coverage of edge cases — AI drafting wins, provided you ask for them explicitly. This is the single largest practical gain.
• Speed to a first draft — AI drafting wins clearly. Hours instead of weeks, and the weeks are made of other people's meetings.
• Proven structure and completeness — Partner templates win. They encode what has gone wrong on other implementations, which is knowledge neither you nor the model has.
• Accountability if it is wrong — Partner templates win. Someone with a contract stands behind them, which matters more than most teams admit before a go-live.
• Institutional learning — Starting blank wins in one narrow sense: writing scripts forces people to think. That benefit is real, and it is not worth six weeks.

The strongest combination is the obvious one: your partner's template as the skeleton, AI drafting to fill it with your processes and your exceptions, your people to correct it. Nothing here argues for dropping an implementation partner.

What AI Cannot Do for a Go-Live

Three things, and they are the ones that decide whether the weekend goes well.

It cannot own the go/no-go decision. That call weighs data quality, business risk, staffing, customer commitments and how tired everyone is. It belongs to a named person with authority, and it should be made against pre-agreed criteria written before anyone was under pressure.

It cannot know your data. Every serious go-live problem I have seen traces back to data — duplicate customers, open items that will not reconcile, a legacy field used for something it was never meant to hold. The model cannot see any of it, and it will happily write a test script that assumes your master data is clean.

It cannot be in the building. Someone has to be there when the load fails at 02:00, when a user cannot post the first invoice on Monday morning, and when the reconciliation is out by an amount nobody can explain. That is embedded, hands-on presence during the critical window, and it is precisely what hypercare support exists to provide — engineers on site through the go-live and the fragile weeks after it.

Getting This Right — Business-Process Confidentiality, Where Outputs Live, and When to Bring in IT

Three practical points before you start pasting process descriptions into a chat window.

What you are actually disclosing. A detailed process description is commercially meaningful: pricing structures, approval thresholds, customer terms, where your controls are weak. Describe processes structurally and keep real data, customer names and specific figures out. Use a business or enterprise tier and read its data-handling and training terms for the tier you are actually on rather than assuming, since consumer tiers commonly differ and terms change.

Where the output lives. UAT scripts and a cutover runbook are project records — they belong in your project repository with version control and an owner, not in a chat history and not in one consultant's personal drive. You will need them again for the next phase, the next entity rollout, and the audit that asks how the migration was controlled.

Who owns it after the model is done. Drafting is the cheap part. Reviewing scripts with business users, reconciling data, staffing the weekend and absorbing the first two weeks of live issues is the work, and it is what our AI+ support practice and managed IT support are built around for exactly this kind of project. Brocent has run managed IT across Asia since our founding in Beijing in 2007, with headquarters in Singapore and a Hong Kong office since 2016 — multi-entity APAC rollouts are our normal territory.

Frequently Asked Questions

Is it safe to describe our business processes to an AI tool?

It depends on how you describe them and which tier you use. Structural descriptions — "orders can ship partially, invoices are raised on despatch" — carry far less risk than pasting price lists, customer terms or actual records. Use a business or enterprise tier, check its current data-handling terms, and keep real data out. If your contracts or regulator prohibit it, the same method works with a self-hosted model.

Won't our implementation partner already provide these?

They will provide templates and a methodology, and you should use both. What partners rarely provide is the specific edge cases of your business, because those live with your staff. AI drafting is how you fill that gap quickly. If your partner is producing complete, business-specific UAT scripts already, you have a good partner and this is less urgent.

How do we validate that AI-written test scripts are complete?

You cannot validate completeness from the scripts alone — you validate it against the process. Have the business owner of each process read the scripts and name what is missing, ask the model to list the assumptions it made, and check the coverage against your actual transaction types over the last quarter. If a transaction type occurred in the business and no script covers it, that is the gap.

What belongs in a rollback plan?

The last known-good state, how to return to it, who decides, how long it takes, and the point after which rollback is no longer realistic. That last item is the one teams avoid writing down, and it is the most important — after the first live transactions are posted, "roll back" usually means "run two reconciliations" rather than "undo".

Who owns go/no-go?

One named person, usually the project sponsor or a steering group chair, deciding against criteria agreed in advance. Write the criteria weeks before the weekend, when nobody is tired and no money has been spent on standby staff. Deciding the criteria in the room at 14:00 on cutover Saturday is how projects go live on a system that is not ready.

Can we use the same approach for a phased rollout to other entities?

Yes, and this is where it pays off twice. Once the first entity's scripts and runbook exist, adapting them for the next country or legal entity is a much smaller job — ask the model to adjust for the differences you describe, then have the local team review. The differences that matter are usually tax, statutory reporting and approval hierarchies.

Where to Start

Pick your highest-volume process, describe it in 500 words, and ask for UAT scripts including negative cases and a list of assumptions. Give the output to the business owner of that process and watch what they cross out — that reaction is worth more than the draft itself, and it tells you how much of your go-live risk is documentation and how much is data. If the answer is that the paperwork is manageable but nobody is available to run the weekend and the fortnight after it, that is a resourcing conversation worth having early — get in touch.