I wouldn't say there's an easy way, but it can be done. Before you go down that path, do you really need to?
You can establish links between files that function pretty much as though the two files were merged even though they are separate, even perform scripts in external files. That should allow you to "easily pass data" from one to the other.
That is a good point. I need to decide what will be best for future maintenance of these DBs. Basically we have several Filemaker solutions that are used to manage work flow and expedite daily operations. These are currently all separate databases with a few shared tables - such as the Clients table, Vendors table and Staff table. ex: There is one Staff table and the other DBs are give access to this via external data sources. I guess I could develop one Filemaker DB that mimicked all of these external solutions, effectively combining them. What I need to consider I suppose is whether this is the best approach from long term stability and growth of the system?
OR - would it be better at this point to rebuild all of the DBs into a single Filemaker solution putting all the application resources into one file?
There is a utility out there somewhere called FMMigrator. I haven't used so can't recommend for or against, but it's worth a look.
You can merge database files using just filemaker but it's a lot of work and requires careful attention to picky details and lots of back ups.
You can use Import Records to import a table from one file to another. You can get both the data and the field definitions in one import. If there are any calculation fields that refer to other tables/table occurrences that are not present in the new file, they'll be enclosed in /* comment */ symbols so that you can make what ever changes to database files or the calculation to fix them.
You can copy and paste layout objects from one layou to another.
You can import scripts.
You can use the clipboard to copy and paste the custom values from a value list.
Relationships cannot be imported/copy-pasted.
Neither can you import value list definitions that specify fields.
Scripts, layouts and calculation fields may refer to other database elements not present in the merged file and will be "broken" until you fix them. You can minimize these if you put some thought into which section are imported first, but you still have to do a lot of checking after you think you are done. FMP advanced's database design report can be invaluable.