# Data Center Challenges and Requirements **URL:** https://forum.networklessons.com/t/data-center-challenges-and-requirements/50732 **Category:** Lessons Discussion **Created:** [July 23, 2024, 11:44am UTC](https://forum.networklessons.com/t/data-center-challenges-and-requirements/50732 "2024-07-23T11:44:40Z") **Posts on this page:** 1 **Showing post:** 3
### Author: ![lagapidis](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/lagapidis/32/4949_2.png) [@lagapidis](https://forum.networklessons.com/u/lagapidis) #### Post date: [August 11, 2025, 5:23am UTC](https://forum.networklessons.com/t/data-center-challenges-and-requirements/50732/3 "2025-08-11T05:23:44Z")
Hello Raju I don’t have direct experience with a specific project such as this with the specific vendors you mention, however, I can give you some high-level guidelines for planning and implementing such a migration. Initially, you should define the underlying architecture (i.e. EVPN-VXLAN). Choose your underlay and overlay technologies, and keep a clean L3 handoff between Arista and Juniper fabrics during migration. Your inventory and discovery process should include: - Physical - every spine/leaf ToR ports, uplinks, cable maps optics part numbers and power feeds - Logical - VLAN/VNI mappings, VRFs/RTs/RDs, BGP neighbors, route policies QoS/ACLs, CoPP - Endpoints - servers, LAGs, hypervisors, storage appliances etc - Dependencies: DHCP relays, DNS, monitoring and telemetry The above is just an indicative list of things to record. In any case, you should create a document like a spreadsheet to map the Arista entities to Juniper entities. This will become the blueprint for your translation/migration. Use this blueprint to begin the configuration translation process. Next, this should be used to build a lab/staging environment. This can be virtual or it can be a scaled down physical topology, depending on what equipment you have access to. Here you can test thing like addressing and RT/RD patterns. You can test BGP EVPN peerings and validate operations. Here you can prove your config migration implementation. Then you must choose a migration plan. Typical migration plans follow one of these three: 1. **Rack-by-rack (L2 move + L3 steady):** Extend VLANs/VNIs from Arista to Juniper temporarily, move server LAGs to new Juniper leaves, keep north-south L3 at old fabric until rack drained. 2. **VRF-by-VRF (L3 first):** Stand up VRF on Juniper, move L3 default gateway and advertise routes. L2 may remain local per rack, then move access. 3. **Side-by-side new fabric:** New Juniper fabric peers at L3 to old (EVPN or plain IP). Migrate services in chunks; decommission old later. Typically, 1 or 3 is chosen because it isolates the impact range of failures, and and avoids cross vendor multi homing. Once all of that is done, you get to the pre-cutover checklist, the cutover procedure, and then the post-cutover validation. These should be based on the above work that you have done. Finally you should have a rollback procedure in place with specific checkpoints as you go along. Some pitfalls that you should be aware of: - Optics used by one vendor may not be compatible with those of the other. These should be pre-validated - MTU should be set throughout on all equipment - Cross-vendor multi-homing should be avoided - RD/RT mismatches are easy to create, and difficult to discover and troubleshoot - Some default values such as those for QoS or CoPP or route policies may be different on vendors, and should be explicitly configured - Licensing and features must be prevalidated to ensure that they are operational when migrating to new equipment This is by no means exhaustive, however, it may be a useful starting point for your project. I hope this has been helpful! Laz --- _[View the full topic](https://forum.networklessons.com/t/data-center-challenges-and-requirements/50732)._