Planning for migration to version 7 I am just taking on responsibility for a Drupal 6.2 site. It has some custom modules and some quite poorly organised code which I am working with developers to improve alongside developing new features to the site. And being fairly new to Drupal I am just getting my head around how it all hangs together.

One of the things I want to assess is when we should be planning to migrate to Version 7.


Is it a reasonable assumption that, as a commercial website, we should upgrade to version 7 as support for 6 drops away over the next year or so?
Is it possible to develop and refactor on version 6 in such a way to make that migration as painless as possible when we get to it? 
Is there anything else I should consider as I plan the development roadmap over the next 12 months?
Should you upgrade?

All contrib modules will slowly shift major version. If you don't follow suit, you risk needing to re-invent the wheel more often than otherwise necessary. Most module maintainers have since long ago shifted focus to D7. A few have even begun maintaining their D8 version.

D6 will become unsupported, and have no more security updates after D8 is released.

How do we make it painless?

I don't think there's an answer that can be applied across all sites, but here are some general guidelines.


Features needs to be "released" (warning, lots of reading), and then upgraded by their providing module, and finally re-added to their respective features.
Use the Migrate module to easily test getting content over.
If possible, run both versions at the same time. Hide the fact as well as you can, possibly using a reverse proxy. This is non-trivial to accomplish, but ensures that when you move your last piece of functionality from D6 to D7, parts of your D7 site has been live for a long while already, and you know that it's stable. As one quick example of a relatively general measure one can take to ease this, Entity API can allow you to redefine where an entity reads/writes its data.
Often Contrib-space will solve a common problem that Core later decides to incorporate. Switching to these techniques for problem solving everywhere it's relevant will allow you to "partly" upgrade a current DX site to DX + 1, making the gap during the complete upgrade much smaller.
Two examples of this are below, but this list could probably be much longer:

Use Panels and Page manager instead of modules like Context and Spaces. The Pm+P approach to site building is the foundation of a huge re-write of core for D8.
Use Guzzle instead of Http Client. Guzzle is the official http-client for Drupal 8.



Anything else?

Nothing that comes to mind at the moment.