If the legacy application already has a web service interface of some kind, you may be able to write some transfer code that sends all of that data to a new Rails application, which then structures it however is needed. This avoids any tinkering with the existing database, but may present challenges all its own. If you need to make substantial changes to the data structure anyway, though, it may not be too much extra work.

If you’re comfortable renaming tables and columns inside your database, you may be able to modify the database so that it follows the conventions Rails expects. For a small project with just a few tables, this might be an acceptable path, but it could be a lot of work for an application with many tables. You’ll still, of course, have to write a Rails application that knows how all of the database tables are connected, as Rails won’t pick that up automatically.

Rails was built to work on naming conventions, but if you have to fall back to configuration, you can write model classes that override the usual conventions. A model can specify, for example, that it works on a table other than the one its name suggests by setting a value for self.table_name('table_name'), or it can specify that the primary key is a specific field with self.primary_key('column_name'). The ActiveRecord::Base class offers a lot of control.