You could also quote on a per-project basis. I don't remember where I got this formula from but it's been almost eerily accurate for me:
Expected Time = (optimistic + 4 * most likely + pessimistic) / 6
It depends on the client, the application, what needs to be done, etc. Each situation can be different. I have a client that I took over the maintenance where I do hourly billing. It could go months with little work and then suddenly jump to 10 hours a week for months. I have another where the work is sporadic and they generally want a per project cost.
It would be best to talk with the client to get a better feel for what they need and expect. Then work out the billing arrangement the works for both of you.
It doesn't have to be "all or nothing"... i.e. that either you loose your shirt or the client pays through the nose. ideas:
1. Step into it. Quote a fixed price "evaluation", of say, 4 hours, or two days, or something, enough time that makes you smarter and will allow you figure out the risk and requirements going forward. This will also allow the client to find out what it is like to work with you.
2. Figure out the scope of what is necessary for the application going forward... do they want new functionality, do they want someone available if it breaks?
3. Figure out the risks.... Do they have decent back-ups? Solid hardware for the server, etc.
4. Figure out their required availability.... Do they want support 24/7? Business days? Within 4 hours, etc.
5. Figure out the value of the application. Is it a core business-enabling application, or CRM? What is the percentage cost of the application vs. the value that it is delivering or the capability that it is providing? This might form a basis for thinking about pricing. If a non-profit is using it to research and manage their grant applications, and they are pulling in $75.000 a year with help of the application, that might be a different calculation than a $10 million company that is using their application for a manufacturing resource application which is a core function that automates their assembly process.
6. How complicated is the application? Does it have plug-ins, ODBC connections to a mySQL back-end, WebDirect or CWP code.... etc.
Quote a maintenance contract, so much per month, say, with the response time spelled out. Price enhancements and bug fixes priced as separate projects.
Quote the contract with a built-in number of hours per month with the expectation that the time would be used for fixing bugs and maintenance.
Reduce risk, by Including in the maintenance contract requirements for remedies to any deficiencies such as old hardware.
The first thing I'd do is to run a DDR on the existing solution and take a look at it with a tool like FMPerception.
Knowing the complexity of an existing solution and its potential problems is always important.
I also fancy a fixed pro-year fee, including X hours. After the X hours are used, a per-hour fee.
Most companies are pretty understanding about what it really costs to do things. I would use the 4 hour estimate/evaluation idea to firmly wrap yourself around what is going on currently.
From there you can determine a price for your work/maintenance. I prefer fixed prices and Siplus' idea of an annual service contract with allotted hours is a great one. I would not bill hourly after that but in chunks of hours, maybe 5 or 10.
I have recently been asked to take over a customers database in terms of support & changes from another developer who has lost interest.
How did they pay the last developer? I'd be asking what there prior arrangement was because it sounds like the business itself (if not the developer) was happy with that arrangement. Then you at least have some idea of their expectation.