Write each lesson into what it changes, before the team disperses

Chapter 40 read what the project changed, one measure at a time, and Chapter 39 gave every control an owner who stays. This chapter reads the project itself: the decisions it took, from the inventory of Chapter 2 to the farm Chapter 38 switched off, which of them the evidence proved wrong or late, and where each correction is written so that the next wave, or the next migration, starts from it.

Which decisions would we take differently next time, on what evidence, and where does each change land?

The decision this chapter leads to is a list of lessons, each tied to the evidence that produced it and to the chapter, template or rule it changes, with an owner, written before the project team disperses.

Which projects this chapter is for

Every move from SharePoint Server 2016 or 2019, copied into SharePoint Online (Chapters 8 and 9) or attached to Subscription Edition (Chapter 23), and every wave inside one. The list opens when the first wave closes, not when the project does: a lesson that waits for the closing meeting has already cost every wave after the one that found it. It closes before the team disperses.

A lesson is a decision taken differently

A lesson names a decision, what the evidence later showed about it, and what the next project decides instead. "Validation took longer than planned" names none of them. "Waves were sized by copy time, but validators' sign-off set their end, so the next wave plan sizes them by validators' hours" names all three, and is the first row of the table below. What would change no decision is an observation: keep it in the record, without an owner, and off the list.

A lesson names a decision and a record, never a person. Chapter 8's method depends on people writing unknown where they do not know, and a review that looks for someone to blame teaches the next team to stop writing it. Where a decision was sound on the evidence it had, the lesson is about the evidence: what was missing, and where the next project gets it sooner.

Each lesson also names the record that holds its evidence, and labels that evidence with Chapter 5's quality labels, so that a lesson resting on one person's judgement says so and stays open until a measurement confirms it.

The evidence is already in the project's records

Every earlier chapter left a record, and the lessons are in the differences between what it decided and what happened:

Start with the dispositions. Each was recorded with its evidence and owner before the content moved, so one that changed afterwards is a decision taken differently: a customisation Chapter 15 eliminated that a site turned out to need, a site Chapter 14 classed dormant whose owner appeared at year end, an integration Chapter 22 retired that still called the farm when Chapter 38 listened. The next project does not inherit the disposition, which belonged to this estate. It inherits the change to the method that produced it: the reading it missed, the window that was too short, the owner nobody asked.

Chapter 40's rows not established are lessons already written: each names a before that nobody measured, and the next project's readiness record is where it gets measured.

Where each change lands

A lesson lands in one place, named in its row: the readiness record, the wave plan, a chapter's method as you run it, Chapter 8's verification method, Chapter 6's rules, Chapter 39's controls or Chapter 42's update calendar. A lesson with two places is two lessons; one with none is not finished, however well it is written.

Its owner is the owner of what it changes, not the person who found it: the finder leaves with the team; the document stays. A change to something another team owns is a proposal until that owner accepts it, and until then the lesson is open, with that owner's name and a date.

During the project, a lesson from one wave lands before the next wave starts, in the wave plan or the readiness record, and that wave's plan says which lessons it applied. The closing list is the same list, completed. One reconstructed from memory in the last week rests on the weakest evidence the project has.

Lessons that rest on Microsoft's pages carry a date

Some lessons rest on Microsoft's pages, and the pages change. This book records where they disagreed, with each other or with the platform, or left the answer to be inferred. Cloud hybrid search needs the July 2025 public update on one page and Version 25H1 on another; the first says its endpoints are on Microsoft's URLs and IP address ranges page, "marked for use with Hybrid Search", and that page marks none (Chapters 11 and 25). For SPFx on Subscription Edition, the compatibility reference gives v1.0 to v1.5 and the Version 23H1 page adds v1.5.1 (Chapter 16). What SPMT still carries of classic pages once custom script is blocked for good, its settings page implies without saying (Chapter 28). The six pages linked here still read that way on 7 November 2026.

Write such a lesson with both sources, the date each was read, and what settled it: a rehearsal on a named build, an observation, or "not established". Then name where Microsoft would publish the change that overturns it, and check it there:

• SharePoint Online. The Message centre is "the primary way" Microsoft communicates "the timing of individual changes", and Microsoft cannot give "the exact date a change is made", so the lesson is checked against the tenant. Each post carries a message ID and a last-updated date, and generally "messages expire 30 days after the time period outlined in the message body" (Message centre FAQ; Message centre). The Microsoft 365 Roadmap, now the AI at Work Roadmap, lists features launched, rolling out, in development or cancelled (stay on top of changes). A lesson resting on a post keeps its ID, text and last-updated date, because the post will not last; the reader Chapter 24 named watches for the next.
• Endpoints. Each change to Microsoft's endpoint data is published as a new version, with a changes method and an RSS feed (IP address and URL web service); a lesson about a network prerequisite, hybrid search's included, is checked at each version.
• Subscription Edition. Each public update is in Microsoft's update history, with notes Chapter 42 reads at release. Each feature update's page lists its features by ring: Version 26H2 lists a Full Mode default for AMSI (Antimalware Scan Interface) request body scans under Standard release, while the AMSI page still says "the default configuration for body scan is the Balanced Mode" and gives Full Mode as a default only for Early release.

All checked on 7 November 2026. Whether a web application already in Balanced Mode changes when 26H2 arrives, neither page says, and we do not know. We would record the mode read on each web application, never the documented default: a reading on a named build is evidence; a documented default is a sentence a feature update can change.

The list, written down

One row per lesson. These rows show the shape, not findings from any one project; the owners are roles here, and the list names people who stay after the project:

Before the team disperses

Hold the closing review once Chapter 40's rows are read and before the project closes, with the people who took each decision present: they leave with the team, and the records do not explain themselves. Each lesson then ends in one of four states:

• Landed: the change is in the document it names, with that document's version or date.
• Open: its owner, and the date it lands.
• Not established: the evidence did not settle what to change; the measurement that would settle it is named, with an owner.
• Declined: the owner of what it would change refused it, with the reason.

No percentage of lessons landed, and no grade: a high figure would hide the one declined lesson that mattered most. Keep the list beside Chapter 9's verification record and Chapter 38's decommissioning record, with its own owner. The next project's first readiness review reads it and records, lesson by lesson, what it adopted and why it set the rest aside.

A lesson is learned when the next project's documents change, not when this project's team agrees on it.

Out of scope

Measuring what the project achieved is Chapter 40, the controls handed over Chapter 39, decommissioning Chapter 38, hypercare Chapter 37, waves Chapter 33 and keeping Subscription Edition current Chapter 42. Retrospective formats and facilitation, performance reviews, contractual claims, satisfaction surveys and knowledge-management tools are not covered.

Before you continue

• Every lesson names a decision, the evidence that changed it and the record that holds it, with its quality label
• Every lesson lands in one named chapter, template or rule; what changes nothing stays an observation
• Lessons from each wave reached the next wave's plan or the readiness record before that wave started
• Every owner owns what the lesson changes and stays after the project, with a date or trigger for the next check
• Every lesson resting on Microsoft's documentation keeps the page or post, the date read and where a change would appear
• Where Microsoft's pages disagreed, both are recorded with what settled it, or with "not established"
• No lesson names a person as its cause, and every lesson is landed, open, not established or declined, never part of a total
• The list was written before the team dispersed, and sits beside Chapter 9's verification record for the next project's first review

Download chapter 41 (PDF)Same text, same tables, same sources as this page.