The high-risk approach is to shut down the servers, move them to the new DC, then start them up. It can be done, and I know of organisations that have been successful in doing this, but they knew it was high risk. I have also known of a truck crashing with the result that a lot of kit was too bent to be used.

If anything breaks you could have a service outage until you buy a new server and get everything installed and tested (maybe a week or two or more).

The low risk approach is to build a new environment in the new data centre, while you keep the old environment running. Seriously consider replication from old to new so that you have the same data in both locations. This allows you to do a phased cutover, with very quick fall-back to your old environment if anything breaks.

When we moved from hosted to AWS, we implemented SQL P2P replication, so we had the same daat in the two old data centres and the two new AWS Availability Zones. We then used Route53 to cut over traffic in 5% intervals, so we could be sure that things were behaving before we committed to AWS. This approach had some complexity (P2P across 4 locations), but the ability to switch workload around in a second or two very significantly reduced risk.

You should look at what options are available to you, then work out the risks of each approach and present this to your management. They will sign off on what they consider best for the business, and it is then down to you to implement it. If they go for a high risk approach, make sure your CV is up to date before you start the move - if the company folds because a truck crashes, at least your personal DR plan will be in place.