You can copy and paste objects from layouts in either version. You can't copy/paste the actual layout in either version.
FileMaker Advanced has some tools that help, but merging them will still be a major chore. You can only copy and paste table definitions (Schema), the relationships still have to be manually created in the merged file.
While you can select all objects in a layout and then paste them as a group into a layout of another file, the layout must first be created, based on an identically named table occurrence that refers to a data source table with exactly the same field names. And any layout parts, such as the header, body, sub summary parts, etc have to be created in advance and sized to match the original layout.
And buttons that perform scripts will be broken unless you first import the scripts they perform, but the scripts may have errors if the layouts that they refer to do not exist and have any layout objects such as fields or value lists that they may refer to. This can require pasting the layout objects into the layout , importing the scripts, deleting the pasted layout objects and then pasting them again to avoid a bunch of broken "connections" in either script or layout. You'll have this same issue in Advanced or Pro.
The Database Design Report in FileMaker Advanced can be very helpful in tracking down such broken connections as you can text search it for text such as "missing" or "unknown".
You may find it easier to just keep your files separate and build date source references and script calls to scripts in external files to create a multiple file solution than to try merging them.
There's also a tool called FMMigrator that is supposed to make merging files simpler.
The thing is, each dept will have separate data and not need to relate to each other. I was going to create all separate files, but the good people on this forum advised me not to in another post. I was told that the correct way is to have just 1 file and use permissions to separate access to departments. I'm still at the early stages of development for the second dept. Would you advise I just dev in 1 file or a few? Please keep in mind this solution will be used in a company that is expanding, and I rather take a little extra time in the beginning than deal with problems later on (can managing separate fiels for each dept become tedious?).
Going with separate files or all tables in one file is one of those issues that doesn't always have a clear cut advantage either way.
Leaving the files separate avoids the hassle of having to merge two files into a single unified solution. But any links between data in one file and in another become a little bit more complex to manage due to the need to create external data source references. If you really have departments that don't need to share any data--seems unlikely, then this won't be an issue. But managing account access will also be more complex as you typically have to define and manage identical account names and passwords in each file for any users that have to access more than one file--otherwise they get asked for an account name and password anytime something causes another file in the solution to open for the first time.
Thanks for shedding some light. I am going to go with 1 file to make managing accounts easier. I'll just re develop my second dept into the first file.