Four Go-Live Plan Components

📢
Communication Strategy

Clear channels ensure all stakeholders are informed, aligned, and prepared for go-live.

🔍
Operational Readiness Assessment

Thorough checks confirm all systems are functional, integrated, and ready to support operational needs.

🎓
Training & Support Plans

Comprehensive training and support resources equip teams with the knowledge and tools for a smooth transition.

⚠️
Risk Mitigation Measures

Identifying potential risks and building contingency plans minimises disruption during execution.

Now Create — Deliver Phase Assets

1
Project & Programme Management — Go-live transition plan review, supported by the Go-Live Implementation Plan Template.
2
Project & Programme Management — Go/No-Go gate meeting, supported by the Go-Live Meeting Template.
3
Organisational Change Management — Execute go-live FAQ communication using the Go-Live FAQs asset.
4
Support — Confirm operational readiness against the Operational Readiness Checklist.

Managing the Go-Live — Three Checklist Types

✅
Prerequisite Activities
Activities that must be completed before the production implementation can be executed.
🩺
Health Checks
Performed in production on implementation day to confirm nothing could impact the planned change.
🚦
Implementation Activities
Activities that can only be completed once the approved change start time has been reached.

Risk Categories — Track via RIDAC

⚙️
Technical

Risks related to system functionality, integrations, and performance.

🔄
Process

Risks that affect workflows, automation, and business operations.

🧭
Change Management

Risks related to user adoption, training, and resistance to change.

🔐
Security

Risks related to data security, user access, and regulatory compliance.

📈
Performance

Risks affecting the ability of ServiceNow to operate efficiently.

🏛️
Governance

Risks related to decision-making structures, accountability, and policy enforcement.

💡 RIDAC: Risks, Issues, Decisions, Actions, Request Changes. Capture all six risk categories throughout go-live and beyond in the Project RIDAC Template — discuss each with the customer and keep it live.
⛔
Back-out plans are only invoked for a catastrophic failure during implementation — otherwise, issues should be managed as defects. Tailor the generic checklist below to the specific scenario:
1
Raise an emergency change for the back-out.
2
Disable user and stakeholder access.
3
Roll back the changes causing issues and apply update-set fixes.
4
Perform validation testing on the changes applied.
5
Confirm the Go/No-Go decision.
6
Communicate the back-out and action plan to users and stakeholders.

The 5W1H of Go-Live Communication

📝
What

What is the content and message? Do first-time login instructions need to be included?

❓
Why

Why is communication required — the catalyst — and why this audience? Follow a top-down approach.

⏱️
When

Is it periodic? When is the action or result actually required?

👥
Who

Who is the target audience — involved or affected users? Different plans for different groups, with OCM input.

📍
Where

Where can information be found — KB articles, community portals — and where is it communicated: all-hands, town hall?

🛠️
How

How will the platform be leveraged — campaigns, content publishing, employee forum — and how are questions handled?

Communication Across the Go-Live Timeline

🌅
Pre Go-Live
Set expectations from the outset — reinforce awareness of the change, the reasons behind it, and the impact on individual roles and personas.
🚀
Go-Live
Highlight which applications or modules are going live and whether globally or regionally. Provide KB articles, FAQs, and guided tours.
🌇
Post Go-Live
Clarify how to raise incidents and where to find support contacts. Document reported issues and workarounds to build a knowledge base.

Four Communication Strategy Themes

🎤
Leadership Engagement
  • Inspiring message from the CIO/CTO
  • Town hall to highlight benefits
  • Newsletters, teaser emails, Slack/Teams posts
  • ServiceNow Campaigns & Content Experience Builder
💬
Stakeholder Engagement & Feedback
  • Feature demos for interactive discussion
  • Surveys & questionnaires
  • Engaging questions to drive participation
🎓
Training & User Enablement
  • Targeted training per group — admins, process users, end users
  • Guided tours for self-training
  • How-to docs, FAQs, handover guides in a go-live kit
🛟
Post-Go-Live Support & Continuous Improvement
  • Call out hypercare support contacts
  • Daily hypercare incident reporting to leadership
🔗 A good OCM team is central to effective communication — see the ServiceNow guide on building an OCM communication plan. Communications should run throughout pre-go-live, go-live, and post-go-live, not just on the day itself.

What Is Hypercare?

Hypercare is the period immediately following go-live where an elevated level of support is available to ensure successful adoption. It continues until the solution is stable and end users are fully trained and productive.

Hypercare Goals

  • Assist the project team with managing daily implementation operations
  • Monitor customer service and data integrity
  • Ensure the implementation operates as expected and aligns with project objectives
  • Validate that support resources are sufficiently trained for day-to-day maintenance
  • Manage operational stabilisation activities and report status to project leadership

Hypercare FAQs

Q1
How are reported issues tracked? Incident and Request Management are the preferred processes; initial defect reporting is resource-intensive and tapers off as stabilisation continues.
Q2
How long should hypercare run? A minimum of two weeks as leading practice — ultimately customer-dependent. Transition to normal support at the conclusion.
Q3
How is feedback gathered? Surveys configured in ServiceNow, with the OCM team analysing feedback to identify improvement areas.
Q4
How are new demands managed? The ServiceNow Agile application can be used to manage enhancements and stories.
💡 Hypercare marks the initial introduction of the solution to a larger user audience — excellent user support during this time is critical to the success of the implementation.

Six-Step Troubleshooting Process

1
Gather Information — collect symptoms, error messages, and recent changes from users or stakeholders.
2
Analyse Error Messages — research their meaning via ServiceNow documentation or community resources.
3
Review System Logs — check System, Event, or Error logs for entries that correspond to the issue.
4
Check Configurations & Customisations — examine related business rules, workflows, and custom scripts.
5
Reproduce the Issue — replicate the problem in a test or non-production environment to isolate conditions.
6
Document Findings & Solutions — keep detailed records to support future troubleshooting and knowledge sharing.

ServiceNow Log Types

📋
System Log

General-purpose log recording platform activity: info, warnings, and errors from scripts, business rules, and workflows.

⚡
Events Log

Tracks events triggered by scripts, workflows, or system processes and queued for processing (notifications, flows).

❌
Errors Log

Records error messages and exceptions raised in the system — script execution, integrations, and system processes.

🔁
Transactions Log

Captures every client–server transaction, including response time, duration, SQL queries, and script execution.

✉️
Emails Log

Tracks outbound and inbound emails processed by ServiceNow.

Quick Reference — Common Issue Triage

1
Flow issues — review flow executions to see where the process is failing or getting stuck.
2
Email & notification issues — check the mail table to see whether the fault is ServiceNow-side or the recipient's environment.
3
Catalog item issues — review UI Policies, which are often the cause of unexpected behaviour.
4
Access & visibility issues — review assigned groups, roles, and ACLs.
5
Cross-instance testing — check whether the issue occurs in other instances, outside production.
6
Business rules & client scripts — review relevant scripts if they could be impacting behaviour.

ServiceNow Support Channels

🎫
Now Support Portal
Submit new support cases, track progress, and communicate directly with ServiceNow support — the go-to channel for complex or urgent issues.
🔎
Known Error Portal
Documented product defects, available workarounds, and whether a fix is planned, released, or scheduled — check here first.
📚
Knowledge Base
Curated articles: how-to guides, configuration steps, troubleshooting methods, best practices, and release notes.
📖 Documentation is the official, authoritative library explaining how the platform works, updated each release. Community is a peer-to-peer forum offering real-world solutions that may not appear in the formal Knowledge Portal.

Common MID Server Issues

🔴
MID Server Not Running

Integrations fail to execute, jobs sit pending, or status shows 'Down'. Causes: service crashes, reboots, resource exhaustion.

🌐
Network Connectivity Problems

Firewall blocks, DNS misconfiguration, or outages. Symptoms: connection timeouts and failed pings.

🔑
Authentication Failures

Incorrect credentials or missing permissions. Symptoms: repeated login failures, access denied, failed discovery jobs.

🧩
Capability Mismatches

Missing required capability (e.g. SSH, JDBC). Related jobs fail or don't appear as options.

Five-Step MID Server Diagnostic

1
Verify MID Server Status — confirm it's running and registered; restart the service if necessary.
2
Review MID Server Logs — analyse for error messages or warnings that indicate misconfiguration.
3
Test Network Connectivity — use ping, traceroute, or telnet to check firewall or DNS issues.
4
Validate Credentials & Permissions — confirm the MID Server user has mid_server / mid_server_admin roles, and check config.xml.
5
Confirm Capabilities & Version Compatibility — verify Java version support and update MID Server binaries if outdated.

Key MID Server Log Files (agent/logs/)

🧾
wrapper.log
Service start-up and shutdown issues.
⚙️
agentX.log
MID Server core operations.
📡
ecc_queue logs
Communication between the MID Server and the instance.
💡 Look for ERROR or WARN entries first — they usually point straight at the failing component before a deeper log trawl is needed.

Rollback Types

📦
Applications
Removes code, table, and file updates from the last install/upgrade. Role: admin. App must be from the Store or Application Repository. Affects only the last install, not the global app record.
🧬
Clones
Returns a target instance to its pre-clone state. Role: clone_admin. Must be done within 7 days (2 for sharded instances). Status: Rolled Back or Rollback Failure.
🩹
Patch Upgrades / Plugins
Role: admin. Only between patches in the same release, one step at a time, within 10 days. Requires Restore Deleted Records & Delete Recovery plugins. Deletes data — complicates later debugging.

Rollback Contexts — Database Support

MySQL & MariaDB
Support both rollback contexts and delete recovery — reverse upgrades, plugin activations, and recover deleted records within the supported window.
Oracle
Supports rollback contexts to reverse certain changes, but does not support delete recovery for restoring deleted records.
SQL Server
Does not support rollback contexts or delete recovery — alternative backup and recovery strategies are required.

Recover Deleted Records

🗑️ Deleted Records Module 7-Day Window
Recovers records deleted from audited tables within the last seven days via System Definition > Deleted Records. Limited to tables with auditing enabled.
♻️ Delete Recovery Module 7-Day Window
Restores any deleted record, regardless of auditing, via Rollback & Recovery > Delete Recovery. Best for broader recovery needs.
🛠️ Upgrade Center centralises planning, monitoring, and troubleshooting the entire upgrade process from a single dashboard. SN Utils — a community browser extension not developed by ServiceNow, but widely adopted — speeds up code editing and upgrade tasks. Scripts run via Scripts – Background keep a 7-day Script Execution History for targeted rollback.

Core Concepts

🗂️
Alert Group

A collection of related alerts automatically grouped based on shared patterns or characteristics.

🎯
Pattern Identifier

A specific attribute — issue type or affected system — used to determine whether alerts are related.

🧠
Alert Aggregation Learner

A ServiceNow component using algorithms to analyse and group similar alerts for efficient management.

🏢
Domain Level

Determines how alerts are grouped, e.g. by department or team, via sa_analytics.agg.learner_domain_level.

🤖
Machine Learning

Activated via sa_analytics.specific_patterns_enabled for smarter, pattern-based alert grouping.

Pattern Identifier — Worked Example

10:00
Alert 1 — High CPU usage on Server A
10:05
Alert 2 — High CPU usage on Server A
10:10
Alert 3 — Memory leak on Server B
10:15
Alert 4 — High CPU usage on Server A
💡 Alerts 1, 2 & 4 share the same metric (High CPU usage) and CI (Server A), so they're grouped as a likely recurring issue. Alert 3 differs on both dimensions and remains standalone.

Benefits of Alert Grouping

🔁
Spot Recurring Issues

See related alerts together to identify patterns and address underlying issues before they escalate.

⏳
Save Time & Reduce Noise

Fewer individual alerts to review means faster response and less risk of missing a critical incident.

🎯
Focus on Root Cause

Grouped alerts make it easier to address the underlying cause rather than treating symptoms individually.

📊
Continuous Improvement

Regularly review grouping effectiveness and adjust configuration as the organisation evolves.

Takeaway 01
Plan the Go-Live Like a Roadmap
Use Now Create templates and checklists to align communication, readiness, training, and risk before the transition begins.
Takeaway 02
Change Management Runs the Whole Journey
OCM is important through the entirety of the project, but especially so during the go-live transition. Stakeholder communication is key.
Takeaway 03
Back-Out Is the Exception, Not the Plan
Reserve back-out for catastrophic failure only — manage lesser issues as defects, and always keep a contingency plan ready.
Takeaway 04
Logs Are the Fastest Route to Root Cause
System, Event, Error, Transaction, and Email logs provide critical insight that reduces guesswork and improves accuracy.
Takeaway 05
Structured Troubleshooting Beats Guesswork
Gather, analyse, review, check, reproduce, and document — consistency drives faster, more reliable resolutions.
Takeaway 06
MID Server Stability Protects Integrations
Proactive checks on status, logs, connectivity, credentials, and capabilities prevent disruption and safeguard automation.