The problem with shell scripts usually in that they have too many dependencies on external programs, their output, OS specific behavior. The shell syntax itself is hardly a problem.
There is no easy way to migrate. My scenario would include:
1) Learn syntax of the shell (man shellname). You should understand everything in your shell script before migrating. What, why and how every command works and what do you get in result.
2) Determine what shell was used in previous unix (BTW what kind of Unix)? It can be CSH, TCSH, SH, BASH, ...
3) Determine what external programs where used in every script (every command that is not described in manual page for that shell is an external program). Do they exist on target system? Do they have the same output/return codes? If not, you should either find a substitution for the command, change shell code or even write your own command (when no substitution available).
4) Some external commands are very OS dependent. I.e. 'sysctl', 'pbind'. You should find either existing analogs or try to redesign your scripts for new OS.
5) Test every script (after reviewing and fixing all dependencies) on target OS.
For SQL scripts if they should be executed on the same type of SQL server there is no much problems. They will work. If the target SQL RDBMS is different, some scripts will probably fail. The sequence of migrating still the same: learn old SQL syntax used in script - learn new SQL RDBMS syntax - understand what script is doing - rewrite it - test it. Not easy and not quick.
For complex 250 shell scripts all the process can take months or even failure to migrate (when no substitutions for commands or no SQL functionality exists on Linux).