There is an already accepted answer, but I do have a different opinion - when both loading from one source medium and saving to another target medium are not trivial.
For instance take reading an Excel and storing in a database.
Excel Reader class
One can create an Excel reader with which to traverse the table rows, check the correct column titles, convert date/time values, deal with the last "half" row. Maybe pass a Map of defined columns with their own customizable data validation and conversion.
This class can nicely be unit tested and decoupled of the specific import usage.
Top Importer class (controller?)
The main importing class could have an Excel reader field and do a specific import, storing the values.
Writing to the database could be a separate concern, but I believe that the database
beans will be extended to have adequate inserts and all.
The repository bean(s) of the database
One may consider the injected repository beans, as fields of the importer class are also a form of separating responsibilities.
What one would not like to have is one loop reading and writing, with special handling on both sides.
Also unit tests are much easier, one might store sample data. Test Driven Development is possible.
And finally maybe simpler code and code reuse are now feasible.