Support and change for new system deployments in Scotland
Keep a new system dependable after it goes live
A successful launch is only the start. Stratiis helps Scottish organisations define who supports a new system, how issues reach the right supplier, and how updates and improvement requests are assessed without losing control of the service.
What does support and change mean for a new system?
Support and change is the operating plan for a system after launch. It sets out how users get help, who owns incidents and requests, when the software supplier is involved, and how fixes, updates and process changes are tested, approved and communicated. The exact responsibilities should be agreed before handover.
Why it matters
Give the service a clear owner beyond go-live
When support routes and change decisions are unclear, minor issues linger and useful improvements can introduce avoidable disruption.
Clear help route
Users know where to report a problem or request a change.
Faster coordination
Internal teams and suppliers know when an issue is theirs to resolve.
Safer changes
Updates are assessed, tested and communicated before release.
Useful learning
Recurring tickets and feedback guide the next improvement.
Operating model
What should a support and change plan include?
Agree the practical route from a user's question to a resolved issue or approved improvement.
| Area | What to agree | Useful output |
|---|---|---|
| Service ownership | Who is accountable for business outcomes, technical health and supplier relationships? | Named owners and decision rights. |
| User support | Where do users ask for help, and what information should they provide? | One clear intake and triage route. |
| Incident response | How are impact, priority, communications and escalation handled? | Priority rules and escalation contacts. |
| Supplier boundaries | Which faults belong to the product supplier, IT team or business process owner? | Responsibility and handoff map. |
| Access and requests | Who approves new users, role changes and routine configuration requests? | Request and approval workflow. |
| Updates and releases | Who checks release notes, tests changes and approves deployment? | Change calendar and test record. |
| Documentation | Where are configuration, integrations, known issues and recovery steps recorded? | Current support knowledge base. |
| Review | How are ticket trends, risks and improvement ideas prioritised? | Regular service review and backlog. |
The support model should reflect the application, supplier contract, business criticality and agreed scope of Managed IT Support.
Connected decisions
Review the dependencies that affect support
A reported fault may begin in the application but arise from permissions, records, integrations or an unclear way of working.
Business process
Identify the process owner who can decide whether a request is a fault or a proposed change.
Identity and access
Set a route for sign-in issues, role approvals and leaver access.
Data and records
Agree who corrects records and who investigates missing or inconsistent information.
Connections
Document integration owners, failure alerts and supplier handoffs.
Users and adoption
Use questions and repeat tickets to improve guidance and training.
Security and continuity
Include access reviews, updates, backup responsibilities and incident routes.
How support starts
Move from project delivery to a supported service
Confirm the handover while the project team and software supplier can still resolve gaps.
Map
List users, owners, suppliers, integrations, support hours and critical tasks.
Agree
Set intake, priorities, escalation, approvals and service boundaries.
Handover
Transfer documentation, known issues, contacts and recovery procedures.
Review
Examine incidents and requests, then plan tested improvements.
New System Deployments brings these decisions into the wider implementation and launch plan.
Roles and boundaries
Know who does what when something changes
Responsibilities vary by platform and contract. Write them down so users do not have to navigate between teams.
Business and system owners
The business owner sets priorities and accepts process changes. A system owner approves configuration, access and release decisions within the agreed governance.
IT team and software supplier
IT can coordinate access, devices, connectivity, integrations and first-line triage where agreed. The product supplier handles application defects and product-specific changes within its support terms. Escalation should have a named owner.
Co-Managed IT Support can help an internal team share these responsibilities.
Handover checks
What should be ready before project closure?
A usable handover is more than a list of passwords and a supplier telephone number.
| Check | Why it matters |
|---|---|
| Support contacts and hours | Users and responders know where help starts and when it is available. |
| Priority and escalation rules | Critical disruption reaches the right people quickly. |
| Configuration and integration records | Support can investigate faults without rediscovering the design. |
| Access and approval process | New starters, movers and leavers are handled consistently. |
| Backup and recovery ownership | Teams know what is protected, how it is restored and who tests it. |
| Known issues and workarounds | Open risks remain visible with owners and target dates. |
| Release and test approach | Changes have a route to approval, validation and rollback. |
| Training and user guidance | Common questions have an answer users can find. |
Complete a final support walkthrough with the people who will respond to the first real incident.
Continual improvement
Make changes deliberately as needs evolve
Separate urgent restoration from planned improvement. Both need an owner, but they follow different decisions.
Capture
Record recurring problems, user feedback and supplier notices in one backlog.
Assess
Consider benefit, risk, security, data and connected systems.
Test
Validate important tasks and a rollback route before release.
Communicate
Tell affected users what changes and where to get help.
Use Technology Roadmaps to align larger system improvements with wider business priorities.
Related support
Connect the system to the wider IT service
The right support arrangement depends on the system, the in-house team and the suppliers already involved.
Frequently asked questions
Questions about support and change after launch
Who supports a new business system after go-live?
That depends on the contract and the operating model. The business owner, internal IT team, external IT provider and software supplier should each have named responsibilities and a clear escalation route.
What should happen when a user reports a problem?
Record the impact, affected users and steps to reproduce it. Triage whether it is access, device, connectivity, data, integration, process or product related, then assign the right team and keep the user informed.
What is the difference between an incident and a change request?
An incident is an unplanned interruption or degradation that needs restoration. A change request proposes an adjustment to configuration, workflow or capability and should be assessed, approved and tested before release.
When should the software vendor be involved?
Escalate product defects, vendor-hosted outages and product-specific questions according to the supplier agreement. Share diagnostic evidence and keep one owner responsible for coordinating the response.
How are software updates managed safely?
Review release notes and dependencies, test important workflows and integrations, agree timing and rollback, then communicate the change and watch for issues after deployment.
What should a system handover include?
Include support contacts, service hours, configuration and integration records, access approvals, known issues, recovery responsibilities, user guidance and the route for future changes.
Can Stratiis work alongside our internal IT team?
Yes. A co-managed arrangement can allocate triage, infrastructure, security and supplier coordination between Stratiis and your team. Scope and escalation should be agreed for the particular system.
How often should the service be reviewed?
Review it more frequently immediately after launch. Once stable, set a regular cadence based on business criticality and change volume, using incident trends, user feedback and planned releases to guide decisions.
Discuss your system deployment
Make support part of the launch plan
Tell us which system is changing, who uses it and where support ownership or future changes need a clearer route.
