Before you design your network layout and addressing plan, it is a good idea to find out what needs to be done to simplify future renumbering.
The following message from an ARIN mailing list, recounts one person's experience with IPv6 renumbering:
My organization recently changed IPv6 numbers. We had used EUI64 addressing on servers and used a "subnetting" scheme that was logical and sustainable. It did not require actually touching any servers to change IPs. It was done as such: Add IP prefix to appropriate router interfaces, run find-replace script to fix prefixes in DNS, wait, remove old IP prefixes from router interfaces. While I am not trying to diminish the valid conversation about difficulties involved in renumbering, etc., I am actually doing, and have done this. IPv6 is not IPv4, and there are some aspects of it that change the ways things are/can be done. In our experience, the largest hurdle involved in using IPv6 effectively is getting folks to break out of the IPv4 way of thinking. With larger address spaces come the ability to address interfaces, etc. in a more logical way, that when added to some of the nice things like EUI64 addressing, can make "re-numbering" considerably easier. We do not terminate VPNs, and in fact, because of limitations associated with traditional VPN-V4 L3 MPLS where services like Multicast and IPv6 have been concerned, we don't use that technology (much - we have the luxury of being able to not use it for the most part). We do have a great many downstream members (members to us, most would call them "customers") who use our IP space. One of them is very active with IPv6 (a larger community college of all places, not a major university), and I understand they simply made prefix changes much as we did, as they planned for this eventuality when they initially deployed.
You might also want to have a look at RFC 4192 entitled Procedures for Renumbering an IPv6 Network without a Flag Day to better understand how the process differs from IPv4.