Would you keep troubleshooting a T620 with broken iDRAC?

Before buying parts, separate an iDRAC network problem from an iDRAC initialization problem. Since you get no link light and cannot reach the BIOS or Lifecycle Controller settings, check that you are using the dedicated management port, not another Ethernet port. Also confirm the port and cable with a known-working device.

While XenServer is up, see whether the OS can query the management controller using the appropriate Dell management tools. If it cannot, and the firmware reports the controller disabled or unresponsive, changing its IP will not address the underlying issue. A second board could still be faulty, but identical symptoms make it worth checking the chassis, power connections, and firmware configuration before assuming that.

Given the replacement board and the same behavior, I would stop swapping components until you have a specific test pointing to one. A fault in the chassis or power delivery is possible, but so is a bad replacement board. If the server is stable and your backups are tested, the management-controller failure by itself may not justify another round of parts and labor.

For a production host, though, lack of remote management is a real operational weakness. I would set a firm limit on troubleshooting time, document how to recover the VMs, and compare that effort with a supported replacement or a short-term bridge machine.

I would avoid moving old drives and memory into a different model until you verify compatibility. Drive carriers, controllers, firmware, and memory support can vary, so a used replacement is not automatically a drop-in fix. Check the exact components and whether the target system can run your XenServer version before purchasing anything.

If the remaining service period is only a couple of years, price the whole transition rather than just the server. A tested replacement with known-good parts may be less risky than spending several evenings chasing an intermittent fault, but a desktop is not necessarily a suitable substitute for a production virtualization host.

Short version: keep it running only if the workloads can tolerate the risk and you have a recovery plan you have actually tested. Backups are useful, but also check that you can restore the VMs onto available hardware and that you have the install media, configuration, and licensing details you need.

I would not treat a machine with a failed management controller as healthy just because the VMs still boot. If replacing it is not in budget, set a migration deadline and avoid expanding the workload on it.