To add to Rsf's excellent answer:
You can't "make" management accept anything. You may be able to convince management that migrating your test codebase is a good idea. If you can demonstrate that a migration stands to improve ROI by enabling any of the following advantages you stand a better chance of management approving the change:
- The proposed new framework would allow new tests to be added more quickly than the current framework.
- The proposed new framework would have fewer flaky tests (this can be very difficult to demonstrate).
- The proposed new framework can better manage large numbers of tests (i.e. it is more scaleable).
- The proposed new framework is easier for test automation specialists to learn to work with.
- The proposed new framework allows an easy way for non-automators to add new tests (If you are data driving your tests, this is a feasible argument to use).
- The proposed new framework allows for better integration between the test automation team and the development team (that is, it will be easier for developers to assist with automation and/or use the framework for unit or integration tests).
- The proposed new framework has better support than the current framework.
You are going to have to make this a business proposal, using automator time requirements for maintenance and failure inspection as your proxy for the cost of running the current automation solution. If you can demonstrate that your proposed solution will reduce the amount of time needed by test automators to add new functionality, maintain the existing functionality, and analyze test failures, then if that time saving is enough that the test automation team would "earn back" the time to implement the proposed framework within a reasonable period, the business may decide it's worth doing.
Just to illustrate (numbers are pulled from nowhere: this is not a realistic scenario):
Let's say your current automation team needs, on average:
- 12 hours per week analyzing test results
- 12 hours per week maintaining the current codebase (making changes to account for changes made to the AUT)
- 30 hours per week adding new functionality (i.e. new tests for new features)
That's a total of 54 hours per week dedicated to keeping the current test framework running and up to date.
If it's going to take 400 hours to convert the existing framework, and after that maintenance will be:
- 5 hours per week to analyze results
- 3 hours per week to update to handle code changes in the AUT
- 30 hours per week to add new tests for new AUT features
You will have a total time of 38 hours per week to keep the test framework current - 16 fewer hours than the old framework needs.
That means that you will "earn back" the 400 hours conversion time in 25 weeks - just on 6 months. That's an attractive proposal for a business.
Obviously the numbers aren't that simple, and your projections will be largely guesswork, but being able to give this kind of information in a proposal gives you a much stronger case.