Good questions, so let s see:

1. (when to start porting)
   This certainly depends on the complexity of the modules to port. If there are really complex/large ones, it might be useful to start early in order to find tricky spots while not being under pressure. For smaller/standard ones, I d try to find a bigger time slot later on where I can port many of them in a row in order to get the routine stuff memorized quickly (and benefit from the probably improved documentation).

2. (test coverage)
   Normally I d say that having a good test coverage before starting refactoring/porting would certainly be advisable. But given that Drupal-7 introduces a major change concerning the testing framework by moving it to core, I d expect the need to rewrite a significant amount of tests anyway. So if there is no need to maintain the Drupal-6 versions after the migration, I d save the time/trouble and aim for increased coverage after the porting.

3. (early adopter vs. wait and see)
   Using Drupal since the 4.7 version, we have always waited for at least the first official release of a new major version before even thinking about porting. With Drupal 6, we waited for the views module before porting our first site, and we still have some smaller projects on Drupal-5, as they are working just fine and it would be hard to justify the extra bill for our clients as long as there are still maintenance/security fixes for it. There is just so much time in a day and there is always this backlog of bugs to fix, features to add, etc., so no use playing with unfinished technology while there are more imminent things to do that would immediately benefit our clients. Now this would certainly be different if we d have to maintain one or more official contributed modules, as offering an early port would be a good thing.
   I m a bit in a bind here - being an early adopter certainly benefits the community, as someone has to find that bugs before they can get fixed, but on the other hand, it makes little business sense to fight hour after hour with bugs others might have found/fixed if you d just waited a bit longer. As long as I have to do this for a living, I need to watch my resources, trying to strike an acceptable balance between serving the community and benefiting from it :-/

4. (quality standards)
   "If it works, I m happy" just doesn t cut it, as I don t want to be happy momentarily only, but tomorrow as well. So one of my quality standards is that I need to be (somewhat) certain that I grokked new concepts well enough in order to not just makes things work, but make them work like they should. Now this is hard to define more precisely, as it is obviously impossible to know if one got it before getting it , so it boils down to a gut feeling/distinction of yeah, it kinda works vs. yup, that looks right , and one has to accept that he will quite regularly be wrong about this.
   That said, one particular point I m looking out for is intervene as early as possible . As a beginner, I often tweaked stuff after the fact during the theming stage, while it would have been much easier to apply the fix earlier in the processing chain by means of one hook or the other. So right now, whenever I m about to adjust something in the theme layer, I deliberately take a small time out to check if this can not be done more cleanly/compatible within a hook earlier on. As I expect Drupal-7 to add even more hooking options, this is something I will pay extra attention to, as it usually reduces conflicts and sudden breaking of stuff when adding new modules.

5. (common pitfalls)
   Well - mainly porting to early, finding out afterwards/in between that one or more needed modules were not available for the new version at all, or only in dev/alpha/early beta state. So I d make sure to compile a complete list of used/needed modules first, listing their porting state, along with a quick inspection of their issue queues.
   Besides that, I have so far always been very pleased with the new versions and their improvements, and I m looking forward for Drupal-7 again.

6. (refactoring while porting)
   One could say that porting is a rather large refactoring in itself, so there is no need to add to the complexity by restructuring non porting related stuff. On the other hand, if you already have to shred your modules to pieces anyway, why not use the opportunity to make it a major overhaul? I d try to draw a line based on complexity - for big/complex modules, I d do the port as straight as possible, and refactor more later on, if need be. For smaller modules, it shouldn t really matter, as the likelihood of introducing subtle bugs should be rather small.

7. (other stuff)
   ... need to think about it ...

Ok, other stuff:

• Resource needs - given some of the Drupal-7 threads, it looks like they are likely to go up, so this should be evaluated before porting smaller sites that sit on a shared/restricted hosting account.

• Latest versions first - This one is rather obvious and always stressed in the upgrade guides, but nevertheless worth mentioning: Upgrade core and all modules to their latest current version first before doing a major upgrade, as the upgrade code is highly likely to depend on the latest table/data structures to work correctly. Given Drupals piecemeal , one step at a time update strategy, it would be very hard to implement upgrade code that would detect different pre-upgrade states and acted accordingly.