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.