Here's how I'd approach this:
Analyze and rank the test cases by risk - First, I'd go through and analyze the manual test cases, looking to rank them in a way that helps decide on the automation approach. Some of the factors I'd consider are:
- Impact - What would happen to a customer if this test case were to fail in production? A simple 1 to 5 or 1 to 3 scale is enough - you don't have to be super-detailed on this. I typically work on something of the order of 1 = unusable, 2 = it can be worked around but is a major pain, 3 = the workaround is a nuisance, 4 = it's irritating but it doesn't stop anything, and 5 = who cares?
- Probability - Making this decision will take a bit of data diving in your bug reporting tool. Again, a simple ranking will give you a broad measure. The more often the test case fails, the higher the ranking.
The combination of impact and probability will give you clusters of test cases grouped from most likely to fail and give you problems to least likely to fail and give you problems. In essence, it's a modified risk analysis.
Start with the highest risk group and analyze for automatability - Next, I'd take the highest risk group of test cases, and analyze them looking at these factors:
- What would it take to automate - If it's going to take hundreds of hours to get a flaky automation, it's better off handled as a manual test case. On the other hand, if it can be quickly and reliably automated, it should be.
- Can dependencies be isolated - Manual tests will have dependencies, but a unit test or other form of automated test could potentially reduce the dependencies and test the key functionality.
No matter how you rank them, this is very much a subjective assessment that will depend on how your application code is structured, the strengths and weaknesses of your teams, and the tools you have available to you.
Your best case scenario is that the functionality covered by these tests is so rarely used and so rarely breaks it's not important to test it at all, manually or through automation. You're not going to get support for a decision like that without hard numbers, which means the analysis and some guesstimates on numbers are essential.
Include the time it takes to manually run the test cases each release cycle - and don't forget to note that this is time your testers can't spend looking for other issues in the code.
Consider a long-term approach - Possibly the simplest approach you can work on is to work with your development team to add unit tests around any module in the code that lacks them whenever they work in one. That way each time a bug is reported against a legacy function, that function will get unit tests built as part of the correction. Gradually this will improve both developer understanding of the older code and your automated test coverage over time.