Kurt Lewin's model is nearly eighty years old, gets three sentences in most change management courses, and is regularly dismissed as too simple to be useful. It has also outlived almost everything published since, because it makes one point that organisations keep having to relearn: changing is the short part. Loosening the old way beforehand and setting the new one afterwards is where the work is, and both are routinely skipped.
Watch a typical software rollout and the pattern is unmistakable. There is a go-live date. There is training in the two weeks before it. There is a support period after it. There is nothing at all about dismantling the way people currently work, and nothing about what happens ninety days later when the project team has moved on. In Lewin's terms, the plan consists entirely of stage two.
This guide covers all three stages, what each one actually requires when the change is a piece of software, and force field analysis — the technique from the same body of work that most summaries omit, and the more immediately useful half. For the wider process, see our change management guide; for the launch mechanics, the software rollout plan.
Key Takeaways
- Unfreeze, change, refreeze — and two of the three usually get no budget. Most rollout plans are pure stage two with a launch date in the middle.
- Refreeze is not optional. A change that is never made the default melts back over the following quarter, which is what the post-launch usage trough actually is.
- Force field analysis is the practical half of Lewin. List what pushes towards the change and what holds the status quo in place, then work on the second list.
- Remove restraining forces rather than adding pressure. Both move the change; only one raises tension that resurfaces as workarounds.
- The status quo is held in place by structure, not attitude. The old report, the old permission and the old target do more to block adoption than any opinion.
- Lewin explains, Kotter plans. Use the three stages to justify the shape of the project, and a step model to schedule it.
What Lewin's Change Model Says
Lewin's change model, in one paragraph
A three-stage description of change proposed by the psychologist Kurt Lewin in the 1940s: unfreeze the current state, make the change, then refreeze the new state so it holds. The metaphor is a block of ice — to turn a cube into a cone you do not push harder on the cube, you melt it, pour it into a different mould, and let it set. The model's value is not the metaphor but its implication: any change that has no melting phase will be resisted, and any change that has no setting phase will revert.
Lewin also gave us the reason those two extra stages exist. He described a stable situation as being in quasi-stationary equilibrium — not motionless, but held still by opposing forces that happen to balance out. That single idea reframes the whole exercise. The question stops being "how do we make people change" and becomes "what is currently holding the old behaviour in place", which is a question with concrete, findable answers.
The Three Stages, Concretely
Make the current way stop feeling inevitable. Establish why it cannot continue, involve the people affected, and start removing the supports that make the status quo effortless.
Test: can someone affected explain, in their own words, why this is happening?
The transition itself. People are learning while still delivering, so they are temporarily slower and more error-prone than they were. Support is the entire job here.
Test: when someone gets stuck, how long until they get an answer?
Set the new way as the default. Remove the old path, change what new joiners are taught, and align whatever people are measured on with the new behaviour.
Test: does a person joining next month ever hear about the old system?
1. Unfreeze — making the status quo stop being free
Unfreezing has an emotional component and a structural one, and organisations tend to attempt the first while ignoring the second.
The emotional component is establishing that the current way has a cost, stated in terms the people affected recognise. Not "we are consolidating platforms" but "you re-key the same order into two systems, and that is where the March error came from". People do not unfreeze because leadership is convinced; they unfreeze because they recognise the problem as theirs.
The structural component is harder and more effective: stop subsidising the old way. As long as the old report is still produced, the old system is still available and the old process still satisfies the auditor, nothing has been unfrozen — the change is competing against a free alternative. Switching off one piece of the old path before go-live does more unfreezing than any amount of communication.
Involvement belongs here too. Lewin's own research found that people who take part in shaping a change adopt it far more readily than people who are informed about it, which is why pilot groups who helped configure the system consistently outperform groups who were handed it.
2. Change — the stage where everyone is worse at their job
The transition is uncomfortable for a reason that has nothing to do with attitude: a competent person using a new system is, briefly, a slower and less accurate version of themselves. They know what good looks like and they are not producing it. That gap is where reversion happens — not out of principle, but because a customer is waiting and the old way still works.
Two things shorten this stage more than anything else. The first is getting people to a real success quickly, so the new tool has produced something before it has cost them anything; our guide to the aha moment covers how to identify what that first success should be. The second is support that arrives at the moment of confusion rather than three weeks earlier in a training room — a walkthrough that appears on the screen where people hesitate, rather than a manual they would have to go and find.
This is also the stage where measurement earns its keep. If you can see which step people abandon, you can fix the transition while it is happening instead of reviewing it afterwards.
Stage two is shortened by help that arrives where people stop, not weeks before they start.
3. Refreeze — the stage that gets cut for budget
Refreezing means making the new behaviour the path of least resistance, so that maintaining it requires no willpower. Concretely, in a software rollout, it means:
- Closing the old path. Not deprecating it in a document — removing access, with a date that has an owner.
- Rewriting new-joiner onboarding. If someone joining in three months learns the old workflow from a colleague, refreeze has failed.
- Realigning what is measured. If a manager's target is still easier to hit the old way, the old way survives regardless of policy.
- Keeping the guidance live. The tours, tips and checklists that supported the transition should stay for people who arrive later, not be switched off at go-live.
- Checking usage at day 90, not day 1. Adoption at launch measures compliance. Adoption a quarter later measures change.
The reason refreeze gets skipped is that it has no event. There is no launch, no kickoff and no demo — only a list of small structural changes that each take a fortnight. Give it a date and an owner or it will not happen.
Force Field Analysis: The Useful Half
Force field analysis is the operational tool that comes out of the equilibrium idea, and it is the part of Lewin's work worth running this week. It takes about an hour with the right people in the room.
Step one: state the change as a specific behaviour, not a tool. "Every quote is created in the new system" rather than "adopt the new CRM".
Step two: list the driving forces pushing towards it and the restraining forces holding the current behaviour in place. Weight each one from one to five. Be honest about the restraining side — it is where the useful material is, and where meetings tend to get polite.
→ Driving forces (typical)
- Leadership mandate and a go-live date
- Compliance or audit requirement
- The old system being retired by its vendor
- Genuine capability the old tool lacks
- Visible early wins from a pilot team
- Peer pressure once a majority has moved
← Restraining forces (typical)
- The new workflow is slower for an expert
- A report that only exists in the old system
- Permissions never granted to the right roles
- A manager's target that the old way hits more easily
- Customers or partners still referencing old identifiers
- No obvious place to ask a question at 4pm on a Friday
- Fear of looking incompetent in front of a customer
Step three — the part that matters: work primarily on the restraining side. This is Lewin's most counter-intuitive and most reliable recommendation. Both approaches produce movement, but adding driving force to a balanced system increases tension, and tension does not disappear — it reappears as workarounds, shadow spreadsheets, quiet non-compliance and, eventually, people leaving. Removing a restraining force produces the same movement at a lower level of pressure.
Put concretely: a mandate plus an unavailable report gets you compliance and a shadow spreadsheet. Building the report gets you adoption. The second option is usually also cheaper than the escalation meetings the first one generates.
Most restraining forces in software rollouts turn out to be structural and fixable — a missing permission, a missing report, an untrained approver, an old identifier still printed on a customer document. Very few are genuinely about attitude, though attitude is what gets blamed. Our guide to user friction covers how to find the ones inside the product itself.
Which Stage Are You Stuck In?
Stalled rollouts have distinctive symptoms depending on which stage was skipped. These three cover most cases.
Everyone attends, everyone nods, nobody changes. Requests for "one more month on the old system" keep arriving with good reasons attached.
Stage 1 was skipped. The status quo is still free. Switch something off, and restate the cost in the affected team's own numbers.Launch usage looks good, then declines steadily. Support tickets are low — not because things are working, but because people have stopped trying and gone back to what they know.
Stage 2 is under-supported. Help is arriving too early and in the wrong place. Move it into the product, at the step where people abandon.The project is declared a success and closed. Six months later, a significant share of work has quietly returned to the old path, and nobody can say exactly when.
Stage 3 never happened. The old path is still open and new joiners are being taught it informally. Close it, and rewrite onboarding.The third symptom is the most expensive because it is invisible without measurement. A retention curve on the new workflow makes it obvious: a curve that flattens has refrozen, a curve that keeps sloping down has not.
Refreeze is measurable: adoption at day 90 tells you what adoption at go-live cannot.
Running the Three Stages Inside the Product
Lewin was writing about groups of people in workplaces, long before the workplace was mostly a screen. When the change is the screen, each stage has a cheaper implementation than the classic one.
| Stage | What it needs | In-product version |
|---|---|---|
| Unfreeze | The cost of the old way made visible, at the right moment | A contextual in-app message where the old workflow is slowest, plus a countdown on the legacy screen |
| Change | Support at the moment of confusion, and a fast first success | Guided walkthroughs on the real screens, a checklist of first tasks, and tooltips at the steps people abandon |
| Refreeze | The new way as default, permanently | The same guidance left running for later joiners, the old route removed, and day-90 usage tracked per team |
The refreeze row is the one people underestimate. Onboarding guidance built for a rollout is usually switched off once the rollout ends, which removes precisely the mechanism that would have taught the next cohort. Leaving it live costs nothing and does most of stage three automatically — the argument our digital adoption guide makes at greater length.
Fair Criticisms of the Model
Lewin gets defended too automatically, so it is worth being clear about the limits.
- "Refreeze" implies a stable end state. In an organisation shipping software continuously, nothing refreezes for long. Read stage three as "restabilise at a new baseline" and the objection mostly dissolves — but the wording does mislead people into treating change as a one-off project.
- It is a description, not a plan. Three stages will not tell you what to do on Monday. That is a genuine gap, and it is why the model is normally paired with a step-based one.
- It assumes a bounded group. Lewin's research was on small groups with a shared context. A change that spans several thousand people in different countries has interactions the model does not describe.
- It is silent about individuals. Two people in the same team can be in different stages, and the model has no vocabulary for that — which is exactly the gap ADKAR fills.
None of these make it useless. They make it a lens rather than a methodology, and as a lens it remains the fastest way to explain to a sponsor why the project cannot end at go-live.
Lewin, Kotter and ADKAR Together
The three models are usually presented as competitors and are far more useful as layers. The mapping is close to exact.
| Lewin | Kotter's 8 steps | ADKAR |
|---|---|---|
| Unfreeze | 1–4: urgency, coalition, vision, volunteers | Awareness, Desire |
| Change | 5–7: remove barriers, short-term wins, sustain | Knowledge, Ability |
| Refreeze | 8: institute change | Reinforcement |
A workable division of labour: use Lewin to explain the shape of the project to sponsors, use Kotter's eight steps to sequence the work, and use ADKAR to diagnose the group that will not move. When all three look healthy and adoption is still poor, the misalignment is usually structural — which is what the McKinsey 7S model is designed to surface.
Lewin in Practice: Do vs. Don't
✅ Do
- Switch off part of the old path before go-live, not after
- State the cost of the status quo in the affected team's own numbers
- Involve the people who will use it in configuring it
- Run a force field analysis and work the restraining column
- Put support where people hesitate, in the product
- Leave the guidance running after launch for later joiners
- Give refreeze a date, an owner and a checklist
- Measure adoption at day 90, per team
❌ Don't
- Treat communication as unfreezing on its own
- Leave the old system running "just in case", indefinitely
- Respond to stalled adoption by adding pressure
- Assume slowness in stage two is resistance
- Front-load all support into the two weeks before go-live
- Switch off the in-app guidance once the project closes
- Declare success at launch-day usage
- Keep a manager's target that rewards the old workflow
Shorten stage two and make stage three automatic
Kompassify puts the help where people hesitate — guided tours, checklists, tooltips and in-app announcements built without engineering time — and shows you where users stop, so a transition is supported while it happens and the guidance keeps working for everyone who arrives later. Free up to 100 monthly active users, plans from $129/month, GDPR-compliant and EU-hosted.
Start for free →The One-Sentence Version
Lewin's model says a change has three stages and most plans fund only the middle one — so before adding pressure to make people move, check whether the old way has actually been made harder, and whether anything at all is scheduled to make the new way permanent.
Frequently Asked Questions
What is Lewin's change model?
Lewin's change model is a three-stage description of how any change happens: unfreeze, change, refreeze. Kurt Lewin proposed it in the 1940s using the metaphor of an ice block — you cannot reshape it by pushing, you have to melt it, pour it into a new mould, and let it set again. The lasting insight is that the middle stage is only one third of the work: without unfreezing, the change is resisted, and without refreezing, it reverts.
What are the three stages of Lewin's model?
Unfreeze: loosen the current way of working by making the reason for change concrete and reducing the forces that hold the status quo in place. Change: move to the new way, which is the messy, temporarily less productive stage where people are learning while still delivering. Refreeze: stabilise the new way so it becomes the default — through defaults, removal of the old path, updated onboarding and reinforcement — so it does not decay when attention moves on.
What is force field analysis?
Force field analysis is Lewin's companion technique. Any current situation is held in place by two opposing sets of forces: driving forces pushing towards change, and restraining forces holding the status quo. You list both, weight them, and then — this is the key point — work primarily on reducing the restraining forces rather than increasing the driving ones. Adding pressure raises tension and provokes resistance; removing an obstacle lets the change happen at lower cost.
Why is removing restraining forces better than adding driving forces?
Because a situation held still by two large opposing forces is unstable and stressful, while the same situation held still by two small ones is calm. Increasing the driving force — more mandates, more deadlines, more escalation — moves the change but increases tension, and tension surfaces later as workarounds, shadow processes and turnover. Removing a restraining force, such as a permission that was never granted or a report that only exists in the old system, produces the same movement without the accumulated pressure.
How do you apply Lewin's model to a software rollout?
Unfreeze by making the current cost visible to the people who will change, involving them in the design, and switching off at least one part of the old process so the status quo stops being free. Change by supporting people while they are slower than they were — guided walkthroughs at the moment of use, easy first tasks, fast answers. Refreeze by removing the old path entirely, making the new workflow the default for new joiners, updating whatever reporting people are measured on, and watching usage ninety days out rather than at go-live.
What is quasi-stationary equilibrium?
Lewin's term for the fact that a stable situation is not static — it is held in place by opposing forces that happen to balance. It matters practically because it reframes the question. Instead of asking how to make people change, you ask what is currently holding the old behaviour in place. Usually the answer is not attitude but structure: the old report is still produced, the old system is still available, and the manager's target still rewards the old way.
What are the criticisms of Lewin's change model?
The main criticism is that 'refreeze' implies organisations can return to a stable state, which fits poorly with environments that change continuously; some practitioners prefer to talk about 'restabilising' at a new baseline. It is also criticised as too simple to plan from — it describes the shape of change without telling you what to do on Monday, which is why it is often paired with a more prescriptive model. Both criticisms are fair, and neither removes its diagnostic value.
How does Lewin's model compare to Kotter's 8 steps?
They are compatible and operate at different resolutions. Lewin describes the shape of change in three stages; Kotter's eight steps are essentially an expansion of those stages into a programme plan, where steps one to four correspond to unfreeze, steps five to seven to change, and step eight to refreeze. Use Lewin to explain to stakeholders why the middle stage is temporarily painful and why the project cannot end at go-live, and Kotter to sequence the work.