Jump to content
Server Maintenance This Week. ×

Switching to new server


This topic is 918 days old. Please don't post here. Open a new topic instead.

Recommended Posts

  • Newbies

Hi - just wondering what measures people might take in the following scenario.

Multiple FM7 files are currently hosted on old hardware (running FMS11) and everything needs to be upgraded. A new server is being prepped running FMS19 but there are a number of legacy plugins which almost certainly won't play well with FM19, so before the plugins are tested and replaced, new hardware is being setup running FMS11. We need to move all of the files from the old hardware to the new hardware and test it in a safe environment which minimises the risk to the live databases. Once this has been checked out, then we can switch off the old server and start using the new hardware.

Initial plans are to verify that all external data sources are set to being local to the test copies of the DB files so that there's no risk of contaminating the data between live and test DB files. Secondly, scripts will be trawled through for any Send Mail steps so that emails are not sent via the test DBs. Thirdly, all relevant script steps need to be checked to see that there aren't any hardcoded file paths to the live server (if that's even possible).

The live and test servers run multiple schedule scripts (though the test server has these currently disabled until all of the above is verified) - the idea being to test everything out, then run the server scheduled scripts and see if we get expected (ie healthy) results.

Can you think of any areas where additional caution should be taken, items I might be missing? All help appreciated :)

Link to comment
Share on other sites

You are aware that data sources can be set in $$variables? And setting these in a launch file will be the way to go?

As pr example:

Set Variable[ $$mainServerCRM, "fm19s00.domain.tld/crm.fmp12" ]

Then in Data Sources set CRM's path is $$mainServerCRM

Edited by ggt667
Link to comment
Share on other sites

  • Newbies
10 hours ago, ggt667 said:

You are aware that data sources can be set in $$variables? And setting these in a launch file will be the way to go?

Yes, I'm aware of that and it's a good reminder / lesson for anyone else. However, unless I'm missing something, I can't see how this will help in this situation as the external datas sources have already been configured via Manage External Data Source in all of the files many years before I got my hands on them :) My request was less to do with configuring a new version of FMS and more to do with transferring the files to a new server (with superior hardware) and running the same FMS version (ie v11),  then going about testing it. At this stage, changes to the files need to be kept to an absolute minimum so I'm looking for any suggestions that will aid the transfer whilst making minimal changes to the database files. 

Thanks for your input of course and sorry if I missed your point.

Link to comment
Share on other sites

On 10/13/2021 at 3:30 PM, igeek Jon said:

Thirdly, all relevant script steps need to be checked to see that there aren't any hardcoded file paths to the live server (if that's even possible).

In case you were wondering, my reply was to this part of your requirements.

Link to comment
Share on other sites

On 10/18/2021 at 4:15 AM, igeek Jon said:

Yes, I'm aware of that and it's a good reminder / lesson for anyone else. However, unless I'm missing something, I can't see how this will help in this situation as the external datas sources have already been configured via Manage External Data Source in all of the files many years before I got my hands on them :) My request was less to do with configuring a new version of FMS and more to do with transferring the files to a new server (with superior hardware) and running the same FMS version (ie v11),  then going about testing it. At this stage, changes to the files need to be kept to an absolute minimum so I'm looking for any suggestions that will aid the transfer whilst making minimal changes to the database files. 

Thanks for your input of course and sorry if I missed your point.

 

A lot depends on how the External Data Sources are set up. In the attached screenshot, the one we use almost exclusively, is:

file:directoryName/fileName

This allows FileMaker Server to look within the same directory as the current file for another file that is connected as an External Data Source. So often our File Path is something like ( where the actual file name is 'data.fmp12' )

file:data

If this is the case for you, most file references should still work when moved to the new server, as long as the folder structure inside the FileMaker Server/Data/Databases/ path is the same ( assuming the server is using the default FileMaker Server database path ).

If, however, the references are something else, there may be more work involved.

Screen Shot 2021-10-20 at 5.17.14 PM.png

Link to comment
Share on other sites

  • Newbies

Thanks Josh - I've been trawling through the external data sources (there are a lot of files) and they're all looking good, however, I've never been too concerned about them. Were there any other ares that you could think of that might raise a concern when switching hardware?

Link to comment
Share on other sites

There are a couple of DDR analysis tools that can help find stuff. I use FMPerception and BaseElements. Mostly FMPerception. With that you could search through the DDR to see if there are references to IP addresses, etc. 

Hopefully all of your stuff is being handled via internal DNS. Then you just need to repoint the DNS to the new IP address. You could also swap the IP address to the new server. All depends on what your IT policies are.

Some "Insert From URL" script steps, "Open URL", and plugin functions specifically might have references to other stuff. 

A big thing is, don't guess, open a copy of the files on the new server and test it to within half an inch of its life. See what is broken.

Link to comment
Share on other sites

This topic is 918 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.