Based only what you have said so far 40 hours is excessive and 4 hours is more reasonable. But some further discovery or prior knowledge of the kind of customizations you have in your site might make 40 hours a reasonable quote. For example, needing to upgrade a few extensions so they are available for 4.6 and do some advanced theming might require 40 hours.

Our upgrade process involves:

1. reviewing the standard native CiviCRM extensions and CMS modules/plugins used and ensuring they are available for the new CiviCRM version,
2. finding and analyzing the native CiviCRM extension built just for the site as well as the custom CMS modules/plugins developed just for the site - they may need adjustment, perhaps significant,
3. reviewing whether there is custom code and / or templates overriding CiviCRM or even using jQuery to adjust the DOM - this is often where some developer time is required during an upgrade,
4. reviewing the theme for CiviCRM customizations and noting they will need to be checked post-upgrade - the more extensive the more risk of breakage during the upgrade,
5. on Drupal sites checking for tweaks and customizations within the views using CiviCRM, or any non-views blocks etc that pull in CiviCRM data,
6. on multilingual or non-English sites, checking for the availability of translations for CiviCRM, native extensions, and CMs modules/plugins,
7. on a complex upgrade this is where we would provide the scope and estimate to the client.

In terms of the actual upgrade process, it involves: 7) backing up the site and restoring it locally, 8) running the upgrade process, 9) addressing issues identified in 1 to 6 above, 10) QA of result, 11) usually deploying site to staging for signoff by other JMA staff and client (skipped for simple upgrades) 12) after signoff upgrading production site, usually by taking it offline during night in primary site timezones, doing the upgrade, deploying the changes from 9 to 11 above, and putting it back online.

A) In browser CiviCRM configuration changes like creating custom fields and profiles don't require extra work to upgrade. B) More references to pages in CiviCRM from the CMS don't create extra work on upgrades. C) The use of each additional standard extension, module and/or plugin slightly increases the risk of extra work. D) The more code in extensions, modules/plugins, themes and especially custom PHP and Smarty template override files developed just for this site the more likely that developer time will be needed, and that more of it will be needed.

Based only what you have said so far 40 hours is excessive and 4 hours is more reasonable. But some further discovery or prior knowledge of the kind of customizations you have in your site might make 40 hours a reasonable quote. For example, needing to upgrade a few extensions so they are available for 4.6 and do some advanced theming might require 40 hours.

Our upgrade process involves:

1. Reviewing the standard native CiviCRM extensions and CMS modules/plugins used and ensuring they are available for the new CiviCRM version,
2. Finding and analyzing the native CiviCRM extension built just for the site as well as the custom CMS modules/plugins developed just for the site - they may need adjustment, perhaps significant,
3. Reviewing whether there is custom code and / or templates overriding CiviCRM or even using jQuery to adjust the DOM - this is often where some developer time is required during an upgrade,
4. Reviewing the theme for CiviCRM customizations and noting they will need to be checked post-upgrade - the more extensive the more risk of breakage during the upgrade,
5. On Drupal sites, checking for tweaks and customizations within the views using CiviCRM, or any non-views blocks etc that pull in CiviCRM data,
6. On multilingual or non-English sites, checking for the availability of translations for CiviCRM, native extensions, and CMs modules/plugins,
7. On a complex upgrade this is where we would provide the scope and estimate to the client.

In terms of the actual upgrade process, it involves:

8. Backing up the site and restoring it locally,
9. Running the upgrade process,
10. Addressing issues identified in 1 to 6 above,
11. QA of result,
12. Usually deploying site to staging for signoff by other JMA staff and client (skipped for simple upgrades)
13. After signoff, upgrading production site, usually by taking it offline during night in primary site timezones, doing the upgrade, deploying the changes from 9 to 11 above, and putting it back online.

To summarize the factors affecting the cost of upgrades:

1. In browser CiviCRM configuration changes like creating custom fields and profiles don't require extra work to upgrade.
2. More references to pages in CiviCRM from the CMS don't create extra work on upgrades.
3. The use of each additional native extension from the CiviCRM extensions directory and standard downloaded CMS module/plugin that interacts with CiviCRM slightly increases the risk of extra work.
4. The more code in extensions, modules/plugins, themes and especially custom PHP and Smarty template override files developed just for this site the more likely that developer time will be needed, and that more of it will be needed.