Solution 1:

Personally I'd go with option 1, but in several steps. Since the new 2012 servers have been configured already, and you've already confirmed that they are correctly functioning as AD / DNS servers, then that side of things is working as it should.

(1)I'd first of all transfer the FSMO roles to the new servers, then wait for a while to ensure no issues surface from that.

(2)Then, make a list of all the functionality that should / must work across the network on a day to day basis, and work out how to test that. I'd suggest asking people in other departments about what they use if possible, as the last thing you want to discover is some critical isn't running that you weren't even aware of.

(3)Out of hours, reassign the 2003 servers IP's to the 2012 boxes, AND set the old 2003 boxes to run on new IP's. That way if you do find something is missing they're still online and available for you to access / check / grab what is required. Work through your check list and make sure everything is working as it should.

(4)Next day, prepare for issues, ensure everyone who might be needed is in and available, and ready to fix anything that comes up. Avoid doing the switch on a day when loads is happening, eg a launch, payday, invoicing day, Monday or Friday. Hopefully nothing will, but it's WAY better to plan for the worst and hope for the best.

(5)Finally once things have been running without issue for a few days, shut the old servers down, but keep them available for a while longer just in case.

The reason I'd avoid Option 2 is that the very things that will likely catch you out, are the same things you wouldn't think to script. Also, with an old setup there's bound to be something somewhere which is hard coded to point to the old servers, and no doubt it'll be something which Group Policy or your scripts wouldn't change.