But you can simply use the same config file format as before, and dump it into a table. I don't know what you hope to gain from having it in a database table, so I don't know if that will work for you.

Flat files have the advantage of being easily accessible. Just start an editor and you can see and edit everything. But why use a database then? A database allows fast access to selected subsets of structured data (i.e. data you can put into rows and columns and every row has a similar item in a specific column)

But where is the structure of a hash or array you dumped with Data::Dumper? It is just one long string that you can store in a column of this table and read out one piece or write in one piece. Normally that can be done with a flat file faster and better.

So the question is, what do you hope to achieve better with a database than with flat files ?

It might be that many of the arrays are shared between different config files. Then Data::Dumper or YAML might make sense.

As you can see I have a hard time finding reasons why a config file should be stored in a database. If you have a convincing reason we could tell you how to do it elegantly

I don't know how many config files that you have. Text based config files are usually (in my experience) "small" some hundred or so lines, not thousands of lines.

I suspect that this evolution will need to happen in steps at least for development. Sounds like you have 2 main classes of applications. Ancient legacy ones and ones that are still under development.

I don't know how you parse these config files now. But I would be thinking about modifying the "under dev" programs with an interface that like a DBI, even if at this stage, a flat file is underneath that.

Depending upon how well or not well the info from these config files has been organized and accessed, this could be easy or very hard. You would want to standardize terminology for say "student_last_name", etc.

Then work on the Database. And then how to export config files to the other legacy applications.

A HUGE THING that I am missing here is the application that replaces all of the individual config file edits. I think that this is where you should start!

So to amend my previous thoughts, I would design the user interface for this "global sys admin" application. Then work on the individual apps.

Connecting to a database in perl requires that you specify host, username, password... stuff that normally goes into a config file. So you'll still need a config file, to access the database, to get the other config file...