Short answer:
When you move a switch from a Classic group to a New Central group, the device keeps its running config; New Central does not factory‑default or wipe it, but it can start layering Central‑managed profiles on top, which may override pieces of your existing config depending on how the new group is defined.
What actually happens when you move groups
• For both CX and AOS‑Switch, Central treats the device as already provisioned and does not auto‑zeroize or replace the full configuration just because you moved it to another group (Classic → New).
• New Central uses a profile model (sites, site groups, device scopes) and will try to import connectivity‑related config (mgmt VLAN, IP, default route, NTP, etc.) into device‑level profiles rather than overwriting everything wholesale.
• Any settings that are not explicitly managed by the new group's configuration (UI, profiles, or templates) stay as they are on the switch, which is why your test VLANs on CX remained after the move.
CX VSF stacks
• CX VSF (or VSX) stacks are onboarded and managed as a single logical switch; Central can import an already‑built stack "with its config as‑is" without breaking the stack or forcing a rebuild.
• Moving that stack between groups (Classic UI group → New Central group) keeps the existing running configuration and stack topology; New Central then evaluates drift vs the group's profiles and may flag "not in sync" if your existing config diverges from what the new group expects.
• The main risk is policy/config drift, not config loss: if you later enable/commit a New‑Central profile that defines VLANs, interfaces, or system settings differently, Central may push those down and partially override what is on the stack.
AOS‑Switch stacks
• AOS‑Switch stacks are similar conceptually: Central treats the stack as one device and does not require you to factory‑default or break the stack to move it between groups.
• Historically, with AOS‑Switch and template/UI groups, you could choose to keep local config and just let Central manage selected pieces (or use templates that largely mirror the running config). That same idea applies here: unless the New Central group is configured to push specific profiles that conflict with your current config, your stack's existing VLANs, trunks, and SVIs remain.
• The risk for AOS‑Switch is again Central overwriting portions of configuration when you start using New‑Central profiles for those features, not an automatic wipe on group move.
Scenarios where you could "lose" config
Not true zeroize, but practical config loss can happen in a few ways:
• You define global or group profiles in New Central that own system, VLAN, or interface settings, and then commit them; Central pushes those down and overwrites conflicting local settings.
• Connectivity import on CX can generate device‑level "local profiles" (VLAN 1, NTP, STP, system admin, etc.); if you later clean those up incorrectly (for example, removing the mgmt VLAN/profile before you have a replacement), you can strand the switch or drop important bits of config.
• If you ever choose an explicit "overwrite all configurations"‑type workflow in the future (some migration/reset flows), that can intentionally replace config, but that is an explicit action, not what you're doing by simply moving Classic → New.
Recommended precautions / best practices
Before moving production CX VSF or AOS‑Switch stacks from Classic to New Central:
• Full offline backup: Save the running config from the stack commander (CX: copy running-config sftp: ; AOS‑S: copy running-config tftp: or similar) and store off‑device. Do not rely solely on Central's backups.
• Test with a representative pair: You already did this with a CX switch and VLANs; I'd repeat with a non‑critical AOS‑Switch stack that has SVIs, trunks, and ACLs to see how New Central models it and what it wants to import.
• Disable auto‑commit initially: For the target New Central group, disable automatic config commit so that when the device joins, you can review the proposed changes/drift before pushing anything back to the switch.
• Keep group config minimal at first: Start with a mostly "observational" New Central group (no aggressive interface/VLAN profiles) so devices move over without big config changes. Then incrementally introduce profiles and watch the diff against your current configs.
• Verify sites and scopes: In New Central, make sure each device is assigned to a site and that any wired profiles are correctly scoped (global/site/device) so you don't accidentally push a global switch profile to all devices and override local settings.
Given your test, what you saw is the expected behavior: the VLANs you created while in Classic remain after moving to a New Central group. The same is true for CX VSF and AOS‑Switch stacks; they will retain config unless you deliberately let New Central profiles override it.
------------------------------
Dustin Burns
Lead Mobility Engineer @Worldcom Exchange, Inc.
ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022-2023
If my post was useful accept solution and/or give kudos
------------------------------