SyteLine go-live and cutover checklist

Short answer

A calm go-live is decided in the weeks before it. Agree written readiness criteria, rehearse the cutover until the timing is known, freeze changes, then run a timed runbook with a named owner for every step and a go/no-go checkpoint before users log in. Before saying "go," prove that orders can be entered, shipped and invoiced, that reports print, that scheduled tasks run, and that the financial balances tie. Keep a rollback point until the go decision is made, and staff the first week for fast fixes.

Readiness: what must be true before you set the date

Area	Ready means
Testing	Business process tests passed and signed off, with no open critical issues
Data	At least two full migration rehearsals reconciled. See the data migration checklist
Reports and documents	Every report the business needs on day one compared against the old output and signed off
Customizations and integrations	Tested end to end in the final test environment
Security	Users, groups and permissions set up and tested by real users. See the security audit
Infrastructure	Servers, printers, email and the background queue tested
People	Key users trained, a support rota agreed for the first two weeks
Rollback	A written plan for going back, and the point after which you can't

If one of these isn't true, moving the date is cheaper than going live anyway.

The freeze

From an agreed point before cutover, stop changes that would have to be repeated: master data changes in the old system go through a controlled list, no new customizations, and transactions are cut off at a set time. Tell the whole business the dates in writing.

The cutover runbook

Write every step in order, with an owner, a planned start and duration, and a check:

#	Step	Owner	Planned	Check
1	Stop transactions in old system	Ops lead	Fri 17:00	Users logged out
2	Final backups	DBA	17:15	Backup verified
3	Final extract and load (or upgrade run)	Data lead	17:30–23:00	Load logs clean
4	Reconcile counts and balances	Finance, data lead	Sat 08:00	Signed reconciliation
5	Inventory load from count	Warehouse lead	10:00	Quantities match count
6	Smoke tests	Key users	13:00	Test list passed
7	Go / no-go	Sponsor	16:00	Decision recorded

Times come from the rehearsals, not guesses. Keep a live log of what actually happened, when, and who did it.

Smoke tests before users log in

Run these in production with real setup and test records, then reverse or void what you created:

Create a customer order, pick, ship and invoice it.
Receive a purchase order line.
Release a job, issue material, report labor and complete it, if you manufacture.
Print the documents that leave the building: invoices, packing slips, pick lists, labels, POs.
Email a report, and confirm it arrives.
Run one scheduled background task, and confirm it finishes and produces output. See Report stuck in WAITING or no PDF.
Post a test journal and confirm GL integration, if finance agrees.
Check that each integration sends and receives one test transaction.
Log in as a few ordinary users and confirm they see the right forms and nothing extra.

SyteLine-specific checks for go-live day

General ERP cutover advice covers most of the plan. These are the SyteLine-specific things that most often catch sites out on the first morning:

Services are running and set to start automatically (on-premises): TaskMan, the Infor Framework Event Service and SQL Server Agent. If any of them is stopped, reports and scheduled tasks quietly stop being processed.
Report Options are correct for the people who print or email documents. Output format, printer and email settings often still point at the test environment.
Scheduled tasks were rebuilt deliberately, with Increment Date set on recurring reports so their date ranges move forward. See How to schedule a SyteLine report or utility.
Form customisations are at Site scope, not a developer's User scope, and FormSync decisions are recorded. See Why SyteLine form changes disappear.
Groups and authorizations match the access matrix, and test or consultant accounts are disabled. See A practical SyteLine security audit.
Orphan session clean-up is switched on (Minutes to close orphan sessions), so dropped connections don't tie up licences in week one. See Find and clear orphan user sessions.
A blocking alert is in place on the SQL Server (on-premises), so a stuck task is an email, not a morning of frozen screens. See Get an email when SyteLine is blocked.

Go / no-go

The sponsor decides against the criteria, not against optimism. The questions are simple: did the data reconcile, did the smoke tests pass, are any open issues severe enough to stop shipping or invoicing? Record the decision and who made it. If it's no-go, the rollback plan runs as written.

The first week: hypercare

Daily stand-up with key users, support and IT, at the start of each day.
One issue list, triaged by impact: can't ship or invoice first, then wrong data, then reports and cosmetics.
Watch the background queue every morning for failed or long-running tasks. A task RUNNING far longer than usual is usually a wrong parameter or a blocked query. See Why a SyteLine task runs for days.
Watch for blocking if users report freezes. See SyteLine freezing for everyone.
Clear orphan sessions safely when users can't log back in after a dropped connection, and never delete $service sessions. See Find and clear orphan user sessions.
Keep the old system read-only and available for lookups.
Run the first month-end with extra time and people.

After hypercare

Move the remaining issues into the normal backlog, write down what you'd do differently, and make sure the new reports, scheduled tasks and customizations are documented. A clean backlog after go-live is easier to keep clean. See Clearing a SyteLine report and data backlog.

FAQ

What should be on a SyteLine go-live checklist?

Signed-off testing, reconciled migration rehearsals, day-one reports compared and signed off, tested integrations, security and infrastructure, trained users, a rollback plan, a timed cutover runbook and smoke tests.

What are smoke tests at ERP go-live?

A short set of real transactions, like entering, shipping and invoicing an order, run in production before users log in, to prove the system works end to end.

Who makes the go/no-go decision?

The project sponsor, against written readiness criteria agreed in advance.

How long should hypercare last after a SyteLine go-live?

Usually one to two weeks of daily support, extended through the first month-end.