You're going to need access to both firewalls likely, in order to change the IP configuration, which will invariably change if you're moving to a different ISP, as each maintain their own netblocks of IPs, which they allocate to their customers either statically or dynamically. Presumably you have the former, but your current ISP will be able to tell you that and/or you can tell by looking at the WAN port configuration on the firewall.
Secondly, I would need to understand how the two servers are connected.
Presumably there's a site-to-site IPSec (VPN) tunnel between both offices, which would be configured on both location's firewalls, providing connectivity between locations, but they could have a LAN extension (MPLS/VPLS) or some other kind of private network that the ISP created and manages between both endpoints (each office).
My guess is that if they're rockin' 2008 Servers, the IT budget would make a LAN extension/MPLS connection between locations cost-prohibitive, but this obviously needs to be vetted and pricing varies wildly depending on where you are. This is something that the current ISP's invoices would have itemized and a call with them would be prudent.
So assuming these are just regular independent Internet connections, and if you can get into the firewalls without having to factory reset them, you can dig around and find the VPN/IPSec/Site-to-Site/LAN-to-LAN whatever (posting the make/model would be helpful).
A simple test is to ping the IP address that's assigned to the interface on Server B, from the command prompt of Server A.
You can run net use from the command prompt of the server with the mapped drive to find out the IP of server B. It may be mapped via DNS too (\\serverb.company.local\some\shared\folder)
I'd thenping -t 192.168.2.2 (or serverb.company.local) which will give you a continuous ping so you can also do things like check the latency while you're at it.
If you get a response from Server B, then you know that there is Layer 3 connectivity between locations and likely an IPSec tunnel. If you can preserve that Layer 3 connectivity, then synchronization should continue to work, in other words, if that mapped drive can stay up, you should be ok.
Having said that, I would first want to ensure that there is synchronization in place and that it does indeed work over mapped drive (which in and of itself does not do any kind of replication/synchronization, it meerly creates a user-friendly mapping for accessing files), because I know I probably would've setup Distributed File System Replication (DFS-R) back in the day if bandwidth was limited, but it comes with it's own headaches (locks, backup can be weird, etc.).
Are you sure that the mapped drive is not just for accessing the data on-demand?
When we setup branch offices nowadays, even with cable modem connections (150/20 Mbps) and IPSec tunnels, we're usually just mapping drives on individual machines at the branch office.
Does each location see the same drives/UNC paths? i.e. Location A accesses shares on \\server-a\some\shares and Location B access shares on \\server-b\some\shares and both those shares have identical files? Can you do a test and create a dummy.txt file and wait an hour and have it show it on the other side? I would really want to know what's actually going on before changing anything.
As to changing ISPs, if there is a LAN extension (MPLS/VPLS) and you plan on getting the equivalent, then you're going to need to coordinate a maintenance window (downtime) and configure the routers at either end; these could be layer 3 switches and they could be routing between themselves, bypassing the firewall entirely; all kinds of topologies you can get into with that.
If my hunch is correct and these are just regular independent Internet connections, then you'll need to reconfigure the site-to-site VPN at each location's firewall, which essentially boils down to:
Remote and Peer IP addresses for identity (office A and office B IP addresses assigned to the firewall, or the first one of the usable range in the subnet provided by the ISP)
Policy agreement on cryptography, encapsulating, and timing (phase 1 and phase 2, IKE version, crypto algorithm, etc.): basically make sure both sides have the same settings. :)
If the tunnel is already there, you just need to change each side's respective remote gateway and peer/local IP address in the configuration, assuming they used IPs as the identifiers, but rarely have I seen it done otherwise: basically look for old IP, replace with equivalent new IP; rinse and repeat.
There are lots of tutorials on how to do this, but they all should use the same IPSec framework to do so.
