Cisco – Upgrading Cisco 500 series stackable switches in stacking mode

I don't think you're going to see any website with direct step-by-step instructions on how to do this. There maybe a few blogs which speak to a blogger's personal experience....however, this is how I would approach it.

I'm going to assume that your current 3560Gs have L3 links to the core and an L2 link (or portchannel) between the two switches. I will also assume that you're using interface tracking to help swap HSRP states and pre-emption and etc...

While you are adding the 3750X to the original 3560G switches. All you would require is to extend the L2 link to the 3750X stack. You can pre-provision the 2nd 3750X and even have it running and connected when you do this entire process.
Then move the L3 uplinks from the standby 3560G to the first 3750X and ensure that HSRP is configured in order to facilitate the failover.
Once that is done...begin migrating your cabling/device cable to the 3750X stack.
Then move the final 3560G L3 link to the 2nd 3750X switch. You should now also be able to remove the L2 link between the 3750'ss and 2560's and power them off.

Since you're using HSRP - the 3750X's should become active under your control (via a priority change)

Finally, after you are left with just the 3750X in a stack-formation. You will no longer require HSRP to run between the two switches since the 3750X will really be seen as one switch all together. Ultimately, the end solution should have 2x L3 uplinks to your core or router, and the VLAN interface existing solely on the 3750X stack. I would also have the each of the L3 links attached to the separate 3750X switches as well.

This final solution should give you a more robust design from preventing spanning tree and HSRP timers from delaying your network re-convergence and allowing the routing protocol to do the upstream path selection instead of HSRP.

I really don't like how Cisco crippled EIGRP in the ipbase image... at a minimum, you should get some kind of warning that your configuration won't work, but they haven't done that either.

As you discovered, eigrp stub prevents EIGRP from advertising downstream routes from the switches connected to your distribution.

You can trick EIGRP into advertising routes it learned from other rotuers (even as a stub router) by using a stub leak-map...

ip prefix-list p~MATCH_ANY seq 5 permit 0.0.0.0/0 le 32
!
route-map r~MATCH_ANY permit 10
 match ip address prefix-list p~MATCH_ANY
!
router eigrp 100
 no auto-summary
 network 172.16.0.0
 eigrp log-neighbor-warnings
 eigrp log-neighbor-changes
 eigrp stub connected summary static redistributed leak-map r~MATCH_ANY

Technically, you can get away with using eigrp stub leak-map indefinitely, without upgrading your ipbase image.