Migrating from Prime Infrastructure to Catalyst Center
Introduction
If you are still running Cisco Prime Infrastructure to manage your enterprise network, the clock is ticking. With Prime Infrastructure reaching End of Sale in September 2023 and the last date of support approaching in 2028, every network team needs a concrete plan for moving from Prime to Catalyst Center. The question is no longer whether you should migrate, but how to do it efficiently, safely, and without disrupting production operations.
This guide walks you through the entire Prime Infrastructure migration journey: understanding the end-of-life timeline, assessing your environment with the PDART readiness tool, executing the actual data migration with PDMT, and following best practices that will save you hours of troubleshooting. Whether you manage a handful of switches or thousands of access points across multiple campuses, the principles covered here apply to your environment.
By the end of this article, you will understand the available migration paths, know exactly which tools to use and how to install them, and have a checklist of pre-migration tasks that dramatically improve your chances of a smooth cutover. This is a comprehensive resource for IT professionals preparing for the transition, and every technical detail comes from real-world deployment experience with these migration tools.
Why Is Migrating from Prime to Catalyst Center Urgent?
The most compelling reason to start your Prime to Catalyst Center migration now is the end-of-life timeline that is already well underway. Here is the complete schedule that every network administrator should have posted on their wall:
| Milestone | Date |
|---|---|
| End-of-Life Announcement | March 31, 2023 |
| End-of-Sale Date | September 29, 2023 |
| End of Vulnerability/Security Support | September 28, 2024 |
| End of Software Maintenance Releases | September 28, 2025 |
| End of Service Contract Renewal | September 28, 2027 |
| Last Date of Support | September 28, 2028 |
Several critical consequences flow from this timeline. First, there are no more device packs being released for Prime Infrastructure. This means that any new hardware you purchase will not be properly supported by Prime. Second, there is no Wi-Fi 7 support in Prime Infrastructure. As organizations begin deploying Wi-Fi 7 access points, Prime simply cannot manage them.
The end of vulnerability and security support in September 2024 is particularly significant. Running a network management platform that no longer receives security patches creates an unacceptable risk posture for any organization that takes security seriously. Every month you delay the migration increases your exposure.
Pro Tip: Do not wait until the last date of support to begin migration. The process involves multiple steps, readiness assessments, potential remediation of data quality issues, and phased cutover. Starting early gives you the runway to handle unexpected complications without pressure.
What Are the Migration Options Beyond Catalyst Center?
Before diving deep into the Catalyst Center migration path, it is important to understand that Catalyst Center is not the only destination. The right choice depends on the types of devices in your network and your long-term architecture strategy.
| Migration Destination | Supported Devices |
|---|---|
| Catalyst Center | Catalyst 9000 (WLC, Switches, Access Points), Routers (ISR 4K and Catalyst 8000 series), Legacy network devices, Third-party devices |
| Cisco Meraki | Existing Meraki platforms, Catalyst 9000 (WLC, Switches, Access Points) |
| Catalyst SD-WAN Manager / SD-Routing | Routers (ISR 4K and Catalyst 8000 series) |
Catalyst Center stands out as the most comprehensive option because it supports the widest range of devices, including legacy hardware and third-party devices through MIB-II support. This makes it the natural successor for most Prime Infrastructure deployments, which typically manage a diverse mix of switching, wireless, and routing equipment.
Several recent enhancements make Catalyst Center a more viable migration target than it was in earlier releases:
- Increased scale to handle large enterprise environments
- Virtual Catalyst Center options available on both AWS and ESXi, providing deployment flexibility
- Legacy and third-party device support through MIB-II, addressing one of the historical gaps
- Prime parity features that close the functionality gap between the two platforms
These improvements directly address the concerns that previously made some organizations hesitant about migrating. The platform has matured significantly, and the combination of scale improvements and broader device support means that even complex, heterogeneous networks can be managed effectively.
For organizations that have been waiting for Catalyst Center to reach feature parity with Prime before migrating, the current release represents a significant milestone. The addition of virtual deployment options on AWS and ESXi is particularly noteworthy because it eliminates the need to procure dedicated hardware appliances in some deployment scenarios, lowering the barrier to entry and enabling proof-of-concept deployments before committing to a full production rollout.
Understanding the Prime Migration Offer for Switching
For organizations with legacy Catalyst switching infrastructure, there is an important migration incentive to be aware of. A specific migration offer exists for Catalyst 2K, 3K, 4K, and 6K switches that provides temporary use rights for a 24-month period.
Key details about this offer:
- It is available by invitation only through a Right-To-Use (RTU) letter
- A Prime Inventory Report is required as part of the qualification process
- The offer is valid specifically for Catalyst 2K, 3K, 4K, and 6K switches
- The temporary use rights last for 24 months
- The invitation provides temporary use rights only; no new licenses are issued
Pro Tip: Contact your account team early to determine eligibility. The RTU letter process takes time, and you want the temporary use rights in place before you begin migrating those legacy switches into Catalyst Center.
This offer is particularly valuable for organizations with large installed bases of older Catalyst switches. It removes one of the primary cost barriers to migration and gives you a two-year window to plan the hardware refresh alongside the management platform transition.
How Does the PDART Readiness Tool Work?
Before attempting any migration, you need a clear picture of what you are working with and whether your environment is ready for Catalyst Center. This is where PDART (Catalyst Center Readiness Tool) comes in. PDART performs non-invasive checks on your Prime Infrastructure to verify several critical factors:
- Use Cases currently configured in Prime
- Scale of the environment (devices, access points, maps, etc.)
- Reports configuration
- Device compatibility with Catalyst Center, including hardware and software versions
- Platform details
- Wireless Templates in use
The output is delivered as a PDF report or as a TarBall containing PDF, Log, and JSON files. This gives you both a human-readable summary and machine-parseable data for detailed analysis.
What Does PDART Check For?
The detailed results from PDART include several valuable checks that can prevent migration failures:
- Duplicate Planned Access Points -- duplicates will cause conflicts during migration
- Site Length -- site names must be fewer than 40 characters
- Latitude/Longitude missing -- geographic coordinates are required for proper site hierarchy in Catalyst Center
- Unsupported Special Characters -- characters such as
",',&,<,>and others will cause problems - Names starting with a space -- leading spaces in site or device names must be cleaned up
Each of these issues should be remediated in Prime Infrastructure before attempting the migration. Fixing data quality problems upfront is far easier than troubleshooting migration failures after the fact. In practice, the data cleanup phase is often the most time-consuming part of the entire migration project, especially in environments that have been running Prime for many years and have accumulated inconsistent naming conventions, orphaned site entries, and incomplete geographic data across hundreds of locations. Treat the PDART report as your migration punch list and work through every finding systematically before moving to the next phase.
Selecting the Right Catalyst Center Appliance
The PDART report also provides guidance on selecting the appropriate Catalyst Center appliance for your environment. Based on the scale data it collects -- number of devices, access points, sites, and other metrics -- the report recommends the appliance tier that can handle your deployment. This is a critical planning step because undersizing the appliance will lead to performance problems after migration.
How to Install and Run PDART
PDART can be installed and executed in two ways: through the GUI (UBF method) or via the CLI. Each approach has different requirements and trade-offs.
| Method | Requirements | Reboot Needed | Complexity |
|---|---|---|---|
| GUI (UBF) | Super Users GUI access on Prime Infrastructure | Yes, PI reboot required | Easy |
| CLI | CLI access and shell credentials on Prime Infrastructure | No PI reboot required | Advanced |
GUI Installation (UBF Method)
The GUI method is the simpler approach:
- Download the UBF file and install it as a normal Software Update in Prime Infrastructure
- Reboot Prime Infrastructure
- Launch PDART through the common launchpad of the migration tools
- Execute the assessment and download the report
This method is straightforward but does require a maintenance window because of the Prime Infrastructure reboot.
CLI Installation
The CLI method avoids the reboot requirement, making it suitable for environments where taking Prime offline is difficult. Here is the step-by-step procedure:
Step 1. Download the latest version of the PDART executable to your PC.
Step 2. Copy it to your Prime Infrastructure server using SCP. First, obtain the SCP credentials from Prime:
vielab-pi310/admin# shell
Enter shell access password:
Starting bash shell ...
ade# cd /opt/CSCOlumos/bin
ade# sudo ./getSCPCredentials.sh
user is scpuser
password is xxxxxxx
Use these credentials with a file transfer tool to copy the PDART binary to Prime.
Step 3. Change the file to an executable:
# sudo chmod 755 pdart
Step 4. Execute PDART from CLI. You must be logged in as the root user:
ade# sudo su -
[root@vielab-pi310 ~]# cd /localdisk/sftp
[root@vielab-pi310 sftp]# ./pdart
####################################################
### ###
### Welcome to Cisco PDART ###
### version: 3.05 ###
### ###
Pro Tip: The CLI method is the recommended approach for production environments where you cannot afford a Prime Infrastructure reboot during business hours. The assessment runs without disrupting Prime's normal operations.
PDART Version Compatibility
Using the correct version of PDART for your Catalyst Center release is essential. The latest version is 3.05 (released October 2024). Here is the compatibility matrix:
| Catalyst Center Version | PDART UBF Version |
|---|---|
| 2.3.7.x | Use 3.10.5 UBF Update 05 |
| 3.10.6 | Included in release |
| 3.9.1 | 3.9 UBF Update 05 |
| 3.8.1 | 3.8 UBF Update 05 |
| 3.7.1 | 3.7 UBF Update 05 |
The UBF file is listed on the download portal with the filename format: CATCAssessmentReadiness_3_X_Update_05-1.0.X.ubf
What Is the Prime Data Migration Tool (PDMT)?
Once PDART has confirmed your environment is ready, the actual data migration is handled by PDMT (Prime Data Migration Tool). Understanding the difference between manual migration and PDMT-assisted migration is key to planning your approach.
| Migration Method | What It Migrates |
|---|---|
| Manual Export/Import | Location Groups, Maps, Inventory |
| PDMT Assisted | Location Groups, Maps, Inventory, Device Credentials, Templates, CMX/ISE Server configurations |
The PDMT-assisted approach is clearly superior because it handles significantly more data types, including device credentials and templates that would be extremely tedious to recreate manually. The tool automates the heavy lifting of transferring your Prime configuration to Catalyst Center.
Installing PDMT
PDMT is installed as a UBF software update on Prime Infrastructure, similar to the GUI method for PDART:
- Download the UBF file
- Install as a normal Software Update in Prime
- Reboot Prime Infrastructure
The latest version is Update 06 (released August 2024). Note that Catalyst Center version 3.10.6 has PDMT Update 06 incorporated directly, so no separate installation is needed on that release.
PDMT Version Compatibility
| Catalyst Center Version | PDMT Version |
|---|---|
| 3.10.6 | Included in release |
| 3.10.5 | Data Migration Tool Update 06 UBF |
| 2.3.7.7 | Update 06 |
| 2.3.5.6 | Update 06 |
| 2.3.3.7 | Update 06 |
| 3.9.1 | Update 06 |
| 3.8.1 | Update 06 |
| 3.7.1 | Update 06 |
Accessing PDMT in Different Prime Versions
The navigation path to PDMT varies depending on your Prime Infrastructure version:
For Prime 3.7 and 3.8:
Administration > Settings > System Settings > General > Prime Data Migration Tool
For Prime 3.9 and 3.10:
The tool is accessible directly from the main menu under Prime Data Migration Tool, reflecting its increased prominence in the later releases.
PDMT Workflow Options and Migration Strategies
The PDMT provides several workflow options that give you fine-grained control over the migration process. Understanding these options is critical because choosing the wrong settings can lead to data loss or incomplete migrations.
Required Access Rights
Before starting any PDMT workflow, ensure you have the correct permissions:
- On Prime Infrastructure: Member of the Super Users group (e.g., the "root" account)
- On Catalyst Center: User with SUPER-ADMIN-ROLE (e.g., the "admin" account)
Required Network Ports
The following ports must be open between the components:
| Source | Destination | Ports |
|---|---|---|
| Web Browser | Prime Infrastructure | TCP 8078 |
| Prime Infrastructure | Catalyst Center | TCP 443, 80, 8009, 9992 |
Pro Tip: If there is a firewall or ACL between Prime Infrastructure and Catalyst Center, or between Catalyst Center and the managed devices, ensure all required TCP/UDP ports are allowed before starting the migration. Blocked ports are one of the most common causes of migration failures.
Multi-Server Migration
PDMT supports syncing a single Prime Infrastructure instance to multiple Catalyst Center appliances. This is useful in distributed deployments where different regions or business units are managed by separate Catalyst Center instances. The multi-server option allows you to define multiple target Catalyst Centers and selectively migrate data to each one.
Automatic Device Synchronization
When you configure PDMT with synchronization enabled, devices such as switches are automatically synced to Catalyst Center when they are added under a synced group in Prime. However, there is an important caveat: maps are NOT synced automatically. Maps must be migrated separately as part of the site hierarchy migration.
Site Hierarchy Migration
The site hierarchy migration workflow gives you granular control:
- Select Campus/Building/Floor to be migrated from Prime
- Select the Parent site on Catalyst Center where the hierarchy should be placed
- Optionally, generate new sites on Catalyst Center during the migration process if the parent structure does not exist yet
Understanding the Sync Delete Behavior
PDMT offers a sync delete option that controls what happens when you uncheck previously migrated sites. This setting has significant implications:
When Sync Delete is enabled: Unchecking an already migrated site will delete it from Catalyst Center as well. This is a destructive operation and should be used with extreme caution.
When Sync Delete is disabled: Unchecking an already migrated site only removes the mapping on Prime. The site and its data remain intact on Catalyst Center. This is the safer option for most production environments.
Handling Missing Address and Geo Coordinates
During the site migration workflow, if address or geographic coordinates are missing from your Prime data, PDMT will display a pop-up that requires you to enter the missing information before proceeding. This is where the PDART pre-check becomes invaluable -- if you fix all missing latitude/longitude data in Prime before running PDMT, you avoid these manual interruptions during the migration.
What If the Migration Fails?
If a PDMT migration step fails, the tool provides downloadable logs for troubleshooting. Always download and review these logs before attempting to re-run the migration. The logs contain detailed error messages that indicate exactly which step failed and why, saving you from guessing at the root cause.
Pre-Migration Best Practices and Checklist
A successful Prime to Catalyst Center migration requires thorough preparation. Here is a comprehensive checklist of tasks to complete before running PDMT:
On Catalyst Center
- Discover all Wireless LAN Controllers (WLCs) -- ensure every WLC in your environment has been discovered and is showing in the Catalyst Center inventory
- Verify Access Points are discovered -- confirm that all APs associated with the discovered WLCs are visible
- Add WLCs to a Building -- WLCs must be assigned to a site in the Catalyst Center hierarchy
- Check Health Data in Assurance -- verify that Assurance is receiving health data from the discovered devices. This confirms that the monitoring pipeline is working correctly
- Handle CRL (Certificate Revocation List) checks -- make sure the 9800 WLC has connectivity to the CRL URL specified in the Catalyst Center certificate. If connectivity is not possible, turn CRL check off on the 9800 WLC or disable it on Catalyst Center
Network Connectivity
- Firewall and ACL rules -- if there is a firewall or ACL between Prime Infrastructure and Catalyst Center, or between Catalyst Center and the managed devices, allow the required traffic on all necessary TCP/UDP ports
Certificate Handling
In earlier versions of PDMT (before version 5), a manual certificate fix was sometimes required before the tool could connect to Catalyst Center. The procedure involved listing and deleting cached TOFU (Trust On First Use) certificates:
Prime/admin# ncs certvalidation tofu-certs listcerts
host=10.101.1.142_443;subject=CN = kong
Prime/admin# ncs certvalidation tofu-certs deletecert host 10.101.1.142_443
Deleted entry for 10.101.1.142_443
This command lists the cached certificates and then deletes the stale entry, allowing PDMT to establish a fresh TLS connection to Catalyst Center. Starting with PDMT version 5, this fix has been automated, so manual certificate cleanup is no longer required in most cases.
Pro Tip: Even with PDMT v5 or later, if you encounter SSL/TLS connection errors during migration, checking the TOFU certificate cache is still a valid troubleshooting step. The automated fix handles the common case, but edge cases may still require manual intervention.
Initial PDMT Launch
Be aware that the first time you open PDMT, it takes some time to initialize as the tool starts up its internal services. Do not assume the tool has hung if it does not respond immediately -- give it a few minutes on the initial launch.
How to Plan a Phased Prime to Catalyst Center Migration
For large enterprise environments, a big-bang migration is rarely advisable. A phased approach reduces risk and gives your team time to validate each stage before proceeding. Here is a recommended phased strategy based on the tools and capabilities discussed:
Phase 1: Assessment (Weeks 1-2)
- Install and run PDART using the CLI method to avoid production impact
- Review the PDF report thoroughly, paying special attention to:
- Device compatibility findings
- Scale recommendations for appliance sizing
- Data quality issues (duplicate APs, missing coordinates, invalid characters)
- Create a remediation plan for all identified issues
Phase 2: Data Cleanup (Weeks 3-4)
- Fix all data quality issues identified by PDART in Prime Infrastructure:
- Remove duplicate planned access points
- Shorten site names to fewer than 40 characters
- Add missing latitude/longitude coordinates
- Remove unsupported special characters from names
- Trim leading spaces from site and device names
- Re-run PDART to confirm all issues are resolved
Phase 3: Catalyst Center Preparation (Weeks 5-6)
- Deploy and configure the Catalyst Center appliance (sized per PDART recommendation)
- Discover all WLCs and verify AP visibility
- Assign WLCs to buildings in the site hierarchy
- Verify Assurance health data collection
- Confirm CRL connectivity or disable CRL checks as appropriate
- Open all required firewall ports between Prime, Catalyst Center, and managed devices
Phase 4: Pilot Migration (Weeks 7-8)
- Install PDMT on Prime Infrastructure (schedule a maintenance window for the required reboot)
- Select a small, non-critical campus or building for the pilot
- Run the PDMT migration with sync delete disabled
- Validate the migrated data on Catalyst Center:
- Site hierarchy accuracy
- Device inventory completeness
- Map placement correctness
- Credential functionality (can Catalyst Center manage the devices?)
Phase 5: Full Migration (Weeks 9-12)
- Migrate remaining sites in batches, validating each batch
- Use the multi-server option if migrating to multiple Catalyst Center instances
- Monitor for any migration failures and review logs promptly
- Gradually transition operational workflows from Prime to Catalyst Center
Phase 6: Decommission (Weeks 13+)
- Confirm all devices are managed by Catalyst Center
- Verify all monitoring, alerting, and reporting functions are operational
- Run a final PDART assessment to compare against your original baseline
- Remove Prime Infrastructure from the network management VLAN
- Decommission Prime Infrastructure server and reclaim resources
- Document the new management architecture, including port requirements and access control policies
- Update your operational runbooks and escalation procedures to reference Catalyst Center workflows
The phased timeline above is a guideline. Smaller environments with fewer than 500 devices and a simple site hierarchy may complete the entire process in four to six weeks. Large enterprises with thousands of devices across dozens of geographic locations and complex template libraries should plan for a three-to-six-month project with dedicated resources assigned to each phase.
Key Differences Between Manual and PDMT-Assisted Migration
Understanding when manual migration might be appropriate versus when PDMT is the clear choice helps you make informed decisions:
| Consideration | Manual Export/Import | PDMT Assisted |
|---|---|---|
| Data Types | Location Groups, Maps, Inventory | Location Groups, Maps, Inventory, Device Credentials, Templates, CMX/ISE Server |
| Automation Level | Low -- requires manual steps for each data type | High -- single workflow handles multiple data types |
| Error Handling | Manual validation required | Built-in error detection and logging |
| Ongoing Sync | Not available | Supports continuous synchronization of device groups |
| Multi-Server | Must be repeated for each target | Native multi-server support |
| Skill Level Required | Higher -- requires knowledge of import/export formats | Lower -- guided workflow |
| Reboot Required | No | Yes (for PDMT UBF installation) |
For the vast majority of production migrations, PDMT is the recommended approach. Manual migration is typically reserved for very small environments or specific edge cases where you need fine-grained control over exactly which data elements are transferred.
One scenario where a hybrid approach makes sense is when you have a large number of custom templates in Prime that require validation. You might use PDMT to migrate the bulk of your data -- location groups, maps, inventory, and credentials -- and then manually review and recreate certain templates that are highly customized to your environment. This ensures that critical configuration templates are validated as part of the migration rather than blindly copied over.
Another consideration is the CMX and ISE server integration. If your Prime deployment is tightly integrated with CMX for location services or ISE for policy enforcement, the PDMT-assisted migration handles the transfer of these server configurations automatically. Recreating these integrations manually requires detailed knowledge of the original server settings, certificates, and shared secrets, making the automated approach far more reliable and less error-prone.
Leveraging New Capabilities After Migration
Once you have completed your Prime Infrastructure migration to Catalyst Center, you gain access to capabilities that were never available in Prime. While this article focuses on the migration process itself, it is worth highlighting what awaits you on the other side:
- Assurance provides real-time network health monitoring with AI-driven insights that go far beyond what Prime's monitoring offered
- Software Image Management (SWIM) streamlines OS upgrades across your device fleet
- SD-Access integration enables intent-based networking with automated policy deployment
- Virtual Catalyst Center on AWS or ESXi provides flexible deployment options that Prime never supported
- Enhanced third-party device support through MIB-II means you can consolidate management of even non-Cisco devices
These capabilities represent a fundamental shift from the reactive, device-centric management model of Prime to a proactive, intent-based approach. The migration effort pays dividends not just in continued support, but in genuinely improved operational efficiency.
It is also worth noting that Catalyst Center continues to receive regular updates with new features, device support, and scale improvements. By migrating now, you position your organization to benefit from the ongoing development investment in the platform. In contrast, Prime Infrastructure is frozen in its current state with no future enhancements, making the gap between the two platforms wider with every Catalyst Center release.
Frequently Asked Questions
Can I run Prime Infrastructure and Catalyst Center side by side during migration?
Yes, running both platforms in parallel is not only possible but recommended. The PDMT tool is designed to work with both systems running simultaneously, syncing data from Prime to Catalyst Center. This allows you to validate the migration incrementally while maintaining Prime as the production management platform until you are confident in the Catalyst Center deployment. The synchronization features in PDMT support ongoing sync of device groups, so changes made in Prime can be reflected in Catalyst Center during the transition period.
Does PDART require a Prime Infrastructure reboot?
It depends on the installation method. The GUI (UBF) installation method does require a Prime Infrastructure reboot after installing the update. However, the CLI installation method does not require any reboot. For production environments where uptime is critical, the CLI method is strongly recommended. You simply download the PDART executable, copy it to Prime via SCP, make it executable, and run it as root -- all without disrupting Prime's normal operations.
What happens if I have devices that Catalyst Center does not support?
Catalyst Center has significantly expanded its device support, including legacy network devices and third-party devices through MIB-II. The PDART readiness tool specifically checks device compatibility and will flag any devices in your Prime inventory that may have compatibility issues. For devices that are truly unsupported, you may need to manage them through alternative tools or plan hardware refreshes to bring them onto supported platforms. Running the PDART assessment first gives you a clear picture of any compatibility gaps.
How long does the PDMT migration process take?
The duration varies significantly based on the size and complexity of your environment. Factors that affect migration time include the number of sites in your hierarchy, the total device count, the number of maps and floor plans, and network latency between Prime and Catalyst Center. For a single campus with a few hundred devices, the migration can complete in a matter of hours. Large enterprise deployments with thousands of devices across dozens of sites should plan for a phased migration over several weeks. The first time PDMT is launched, expect additional initialization time as the tool starts its internal services.
Should I use the sync delete option in PDMT?
For most production migrations, it is recommended to keep sync delete disabled. When sync delete is enabled, unchecking a previously migrated site in PDMT will delete that site and its data from Catalyst Center. This is a destructive operation that can cause data loss if done accidentally. With sync delete disabled, unchecking a site only removes the mapping in Prime, leaving the Catalyst Center data intact. Only enable sync delete if you have a specific operational requirement to keep the two platforms strictly synchronized and you fully understand the implications.
What version of PDART and PDMT should I use?
Always use the latest versions compatible with your Catalyst Center release. As of the most recent updates, PDART version 3.05 (October 2024) is the latest, and PDMT Update 06 (August 2024) is the latest. Check the compatibility matrices provided earlier in this article to match the correct UBF version to your specific Catalyst Center release. If you are running Catalyst Center 3.10.6, both tools are incorporated directly into the release and do not require separate installation.
Conclusion
Migrating from Prime to Catalyst Center is no longer optional -- it is a critical infrastructure project that every organization still running Prime needs to prioritize. The end-of-life timeline is progressing steadily, with security support already ended and software maintenance releases ceasing in September 2025.
The good news is that the migration tooling has matured significantly. PDART gives you a comprehensive readiness assessment without impacting production operations, while PDMT automates the heavy lifting of transferring location groups, maps, inventory, credentials, templates, and server configurations. Combined with a phased migration approach and the pre-migration checklist covered in this article, you have a clear path to a successful transition.
Key takeaways to remember:
- Run PDART first -- always assess before you migrate. Fix all data quality issues before touching PDMT.
- Use the CLI method for PDART in production to avoid the reboot requirement.
- Keep sync delete disabled in PDMT unless you have a specific reason to enable it.
- Prepare Catalyst Center by discovering WLCs, verifying APs, and confirming Assurance health data before starting the migration.
- Plan for a phased approach -- migrate by site or campus, validate each batch, and maintain Prime in parallel until you have full confidence in Catalyst Center.
- Check certificate configurations -- especially CRL connectivity for 9800 WLCs and TOFU certificate caches if you encounter connection issues.
The transition from Prime Infrastructure to Catalyst Center represents more than a platform swap. It is a move from traditional device-centric network management to an intent-based, AI-driven operational model. The sooner you complete the migration, the sooner your team can leverage the advanced capabilities that Catalyst Center brings to the table.
Start with PDART today, build your remediation plan, and take the first concrete step toward a modern network management platform. Visit NHPREP to explore courses that cover Catalyst Center deployment, SD-Access design, and other technologies that will help you get the most out of your new platform.