SCCM 2007 to Current Branch: the upgrade that's really a migration

Microsoft will tell you that you can upgrade System Center Configuration Manager. For estates still on Configuration Manager 2007 in 2018, that sentence is a trap. What you actually need is a side-by-side hierarchy migration to Current Branch — new site servers, new database, client reassignment in waves, and a deliberate package-to-application conversion. Calling it an "upgrade" is how projects get half-funded and fully regretted.

This post is field notes from moving a multi-site 2007 estate that still patched and deployed software for a large enterprise desktop fleet. The numbers are composite; the failure modes are not.

Why side-by-side, not in-place

2007 to Current Branch is not a cumulative update path. The site system architecture, content library, client communication model, and application model all changed across 2012 and again into Current Branch. In-place fantasies die on:

• SQL and OS support. The old site servers are often 2008 R2 / SQL 2008 R2 territory. You will rebuild the platform anyway.
• Site system roles. Distribution points, management points, software update points — reinstall and reattach, do not "upgrade in place" and pray.
• Content. The content library rewrite is real. Plan redistribution time as a first-class schedule item.
• Client versions. You will reassign clients to a new site code. That is a migration operation with rings, not a GPO that updates itself overnight.

We built a new primary site (and, for this estate, a new central administration site topology they actually needed — many 2007 "primaries" were overbuilt; some underbuilt). Coexistence window: both hierarchies alive, clients moved in waves, old site decommissioned only when the last critical collection was empty.

Discovery that decides the schedule

Before buying hardware or Azure VMs for site systems, inventory:

• Package and program count. How many are still advertised? How many have not run a successful install in twelve months? We found nearly forty percent of packages were zombies — keep them out of the conversion backlog.
• Task sequences. OSD is often the reason 2007 still exists. Export and rebuild against Current Branch; do not assume identical step behavior for USMT, drivers, and application installs mid-sequence.
• Software updates. SUP/WSUS topology, maintenance windows, and the truth about whether servers and workstations share rings (they should not).
• Boundaries and boundary groups. 2007 boundary design is frequently IP ranges drawn by someone who left in 2012. Current Branch boundary groups are how content and site assignment behave; redesign them, do not port garbage.
• Client installation methods. GPO, software push, OSD inclusion, manual — each becomes a reassignment path.

Package to application conversion without boiling the ocean

Current Branch wants the application model: detection methods, requirement rules, supersedence, user-centric install where it fits. Converting every 2007 package on day one is a multi-year hobby, not a migration.

Our triage:

1. Top N by install volume and business criticality — convert properly with detection.
2. Line-of-business with complex command lines — convert carefully; test detection until silent repair works.
3. One-off utilities — leave as packages temporarily if Current Branch still allows your support path, with a kill-by date.
4. Zombies — delete. Document the deletion. Celebrate.

Detection methods are where conversions fail. "Exit code 0" is not detection. File version, registry key, and Windows Installer product code checks — with the actual values from a known-good install — are detection. We required a second engineer to break a detection method on purpose before the app went to broad deploy.

Client reassignment waves

Clients do not "just find" the new site. You assign them: client push, GPO with site assignment, or scripted ccmsetup with SMSSITECODE. Wave design:

• Ring 0: IT and pilot collections on known-good boundary groups.
• Ring 1: one business unit with a friendly application owner.
• Ring 2+: by site or building, aligned with DP coverage so first content pulls are local.

Monitor: client health dashboard, MP communication, policy request success, and software center failures. A wave that "finished" with twenty percent non-healthy clients is not finished.

Coexistence rule we enforced: no dual management by accident. A machine should take policy from one primary hierarchy for production apps. Dual-agent confusion is how you get conflicting deployments and phantom compliance.

Boundary groups and distribution points

Content is the silent schedule killer. We stood up new DPs sized for the largest OS image and the Office suite, preloaded critical packages before ring 1, and used peer cache only after we understood the WAN map. Boundary groups mapped AD sites and IP ranges to DP groups with fallback only where the WAN could tolerate it.

The mistake we see: beautiful site servers, three DPs for thirty sites, everyone falling back across the WAN on day one of a wave. Pre-stage or accept multi-week content pain.

Co-management groundwork (without pretending 2018 is 2020)

Current Branch is also the on-ramp to co-management with Intune for customers headed hybrid. Even if co-management is not in scope this quarter, hierarchy design that uses a supported Current Branch release, Azure AD join pilots for a laptop pool, and clean device identity will matter later. We documented what we deliberately deferred — full co-management workloads — so nobody claimed the migration "included cloud management" when it did not.

Software updates during the dual-hierarchy window

You will be tempted to keep patching from 2007 until the last client moves. That creates split-brain compliance reporting. Our preference:

• Stand up SUP in Current Branch early
• Move pilot rings to the new SUP first
• Accept that compliance dashboards will be dual until cutover completes — publish a single "source of truth" for leadership so nobody panics at 70 percent
• Do not run conflicting deployments for the same update from both hierarchies against the same machines

Maintenance windows also migrate. A window that made sense on 2007 collections may brick a Current Branch deployment if collection membership is wrong during reassignment week. Re-validate windows per ring.

OSD: rebuild, do not cargo-cult

Task sequences from 2007 often embed:

• Hard-coded package IDs
• Legacy USMT stores
• Driver packages by model families that no longer match hardware buys
• "Install package" steps that should become application model steps

We rebuild the production OSD sequence in Current Branch against a reference task sequence, then port only the business logic that still matters. The first bare-metal build in the new hierarchy is a project milestone with champagne optional and log review mandatory.

PXE and boot images need new distribution points and often new DHCP options (66/67 or IP helpers to the right DP). Coordinate with the same people who own DHCP failover — see our plumbing notes from earlier this year if your forest is also moving.

Reporting and RBAC

Operations Manager and ConfigMgr reporting users will ask for the old SSRS URLs on day one. Publish the new reporting point, migrate custom reports worth keeping, and delete the rest. RBAC in Current Branch is finer-grained than 2007's habits; redesign roles instead of granting everyone Full Administrator because "migration is hard."

Decommission checklist

When the old 2007 site dies:

• Last client count at zero for production collections
• OSD redirected to new task sequences
• SUP retired; clients scanning the new SUP
• Certificates and published roles removed
• Backups of the old DB retained per retention policy for forensics, not for "we might turn it back on"
• DNS aliases and any GPO-based client assignment cleaned
• Documentation updated so the next hire does not rebuild 2007 "because the wiki still says so"

Timeline honesty

For a mid-size multi-site estate, a realistic side-by-side is months, not weeks: design and build (4–6 weeks), content and app conversion for top N (parallel 6–10 weeks), client waves (depends on ring size and DP coverage), OSD cutover, decommission. Parallelism helps; denial does not. The programs that finish cleanly funded content redistribution and helpdesk surge. The programs that slip treated DP bandwidth as infinite.

Field checklist we actually use

Before first client wave:

1. New site codes documented and DNS aliases planned
2. Boundary groups map AD sites and IP ranges to DPs with measured WAN fallback
3. Top 50 applications converted with peer-reviewed detection methods
4. SUP synchronized and a pilot collection compliant from the new hierarchy
5. OSD bare-metal success on three hardware models from the current buy list
6. Helpdesk wiki updated with Software Center differences users will notice
7. Dual-hierarchy communication plan so nobody deploys the same app from both sides

During waves:

1. Health dashboard reviewed every morning of a wave week
2. Content distribution status for packages required by that ring
3. Rollback: how to reassign a device back if a LOB app breaks (rare, but scripted)
4. Change freeze on unrelated GPO and network work that could muddy RCA

After decommission:

1. Old site servers imaged off and disks wiped per policy
2. Certificates revoked or expired naturally with tracking
3. Inventory proves zero production clients on old site code
4. Lessons learned filed while memory is fresh — especially detection method failures

The migration is done when the old hierarchy is boring to forget, not when the project plan hits a green checkbox.

If you're facing this

If someone sold you an "SCCM 2007 upgrade" as a weekend, push back. Budget a side-by-side Current Branch migration: inventory packages, redesign boundaries, convert the applications that matter, and reassign clients in rings. We run these migrations; bring package counts and WAN diagrams, not just a desire to be "current."