So should I use only one of these two options or both?
It depends - your choice will influence a couple of things when developing the app (this is not about migration):
- how many tasks should be performed when adding and updating data; you have to have all data in sync;
- how the querying will be done.
For instance, if you have a “combined” structure like
- Department (DepartmentID, Description, EmployeesInDepartment)
- Employee (EmployeeID, Name, Salary, HisDepartment)
and there’s new employee to add into the database, you have to add a new employee to the list EmployeesInDepartment within his Department, and set the department in the HisDepartment field of this Employee.
In old times we called this data redundancy 
because the information about the employee’s department is stored twice. In can also happen that the information in EmployeesInDepartment is not the same as in HisDepartment - in that case you have a problem.
And there’s also a querying part of the story: Bubble offers a couple of ways to query the data either way, some approaches are better and quicker than others. Let’s say that you need all the employees in the department; you can do this by:
Department's EmployeesInDepartment
or
Search for Employees [HisDepartment = <department>]
The first approach is quicker, since you already build the list of all employees in department when you put the data in DB. However, if you would like to speed up the data entry for some reason, and you don’t need that particular query, then you can drop the EmployeesInDepartment field and use just HisDepartment.
To be complete, you can find the employee’s department by:
Employee's HisDepartment
or
Search for Department [EmployeesInDepartment contains <employee>]
So, your choice should depend from the insert, update and query actions that you expect to have in the app. You can find some general ideas about apps optimization and “architecture” here.