Phase 4

Rollout and Change

By Redaktion techport.ai, IT-Beratung · Last updated on 21 August 2026

Between a good decision and a system that people use lies the phase where most initiatives fail. Not on the technology. On data nobody looked at beforehand, on training that happened four weeks before go-live, on managers who did not know themselves what was changing, and on a project end declared before anyone had used the system.

A project is finished when the old way has been switched off and the new one works without special arrangements. Everything before that is an interim status.

Typical problems

Data migration starts once the go-live date has already been fixed.
There is a project manager but no person in the department who owns the outcome.
Training happened once, in one week, for everyone, on a system that changed three more times afterwards.
After go-live the old and the new way run in parallel, and the old one wins.
Changes go in on Fridays because things are quieter then.

What we do in this field

We run IT projects so that decisions are documented and delays become visible early. We plan data migrations with analysis, cleansing, test runs and a reconciliation that can be proven. We build rollouts around roles rather than departments and train people when they need it. We support the change with the managers who have to carry it. And we set up a procedure for changes and releases that allows speed without putting operations at risk.

Topics in this field

Supporting the changeWhy technically finished systems stay unused and what helps: involve those affected early, inform managers first, take resistance seriously and measure adoption after go-live.Data migration without surprisesWhy migrations delay projects and how to do it differently: analyse data before planning, cleanse with the departments, run several tests, set acceptance criteria and reconcile provably.IT projects that deliverWhy IT projects fail in mid-sized companies and what helps: fill the roles, limit the scope, document decisions, name risks early and tie completion to actual use.Deploying changes under controlHow changes to systems run in an orderly way: test environment, approval, deployment windows, fallback and documentation. Keep the pace and still protect operations.Rollout and trainingHow introductions land: train by role rather than by department, practise at the right moment, secure support after go-live and measure adoption instead of assuming it.

Häufige Fragen

How do we spot early that an IT project is going wrong?

By three signs. The status has been amber for three weeks with no named action. Decisions get postponed because the person who can decide is not in the room. And the departments ask the same questions in testing that they asked in the requirements workshop. Each of these is fixable if someone says it out loud.

Do we need agile methods or classic project management?

Both work if the roles are filled. For standard software with a fixed introduction, a classic plan with clear milestones fits better. For custom development and for initiatives where requirements are still growing, an iterative approach is superior. What works in no model is a department that gets no time for the project.

Let us talk about your situation

In a thirty minute first call we work out where your biggest lever sits and whether we are the right people for it.

Arrange an initial call Our consulting