Title of Invention: Dynamic migration script management Abstract: Various embodiments for managing migration between server systems are presented. Indications of a plurality of migration scripts to be executed during a migration of a database system from a source server system to a target server system may be received. An execution order for the plurality of migration scripts may be determined based upon characteristics of a plurality of database objects to be migrated using the plurality of migration scripts and characteristics of the plurality of migration scripts. Execution of a first migration script of the plurality of migration scripts may be initiated according to the determined execution order. The first migration script may cause copying of a database object of the plurality of database objects from the source server system to the target server system. Detailed Description: Part general_description_paragraphs: Part CROSS-REFERENCES TO RELATED APPLICATIONS: The present application is a continuation of U.S. patent application Ser. No. 13/937,486, filed on Jul. 9, 2013, which is related to the following co-pending and commonly assigned U.S. Patent Applications: U.S. patent application Ser. No. 13/937,977 filed Jul. 9, 2013, now U.S. Pat. No. 9,442,983, issued Sep. 13, 2016, by Higginson and entitled “METHOD AND SYSTEM FOR REDUCING INSTABILITY WHEN UPGRADING SOFTWARE;” U.S. patent application Ser. No. 13/938,061 filed Jul. 9, 2013 by Davis and entitled “CONSOLIDATION PLANNING SERVICE FOR SYSTEMS MIGRATION;” U.S. patent application Ser. No. 13/938,066 filed Jul. 9, 2013, now U.S. Pat. No. 9,098,364, issued Aug. 4, 2015, by Davis and entitled “MIGRATION SERVICES FOR SYSTEMS;” U.S. patent application Ser. No. 13/937,885 filed Jul. 9, 2013 by Higginson and entitled “DATABASE MODELING AND ANALYSIS;” U.S. patent application Ser. No. 13/937,868 filed Jul. 9, 2013 by Higginson and entitled “AUTOMATED DATABASE MIGRATION ARCHITECTURE;” U.S. patent application Ser. No. 13/937,344 filed Jul. 9, 2013, now U.S. Pat. No. 9,491,072, issued Nov. 8, 2016, by Raghunathan et al. and entitled “CLOUD SERVICES LOAD TESTING AND ANALYSIS;” U.S. patent application Ser. No. 13/937,483 filed Jul. 9, 2013 by Raghunathan et al. and entitled “CLOUD SERVICES PERFORMANCE TUNING AND BENCHMARKING;” U.S. patent application Ser. No. 13/937,988 filed Jul. 9, 2013, now U.S. Pat. No. 9,747,311, issued Aug. 29, 2017, by Buehne et al. and entitled “SOLUTION TO GENERATE A SCRIPTSET FOR AN AUTOMATED DATABASE MIGRATION;” U.S. patent application Ser. No. 13/937,545 filed Jul. 9, 2013 by Buehne et al. and entitled “ONLINE DATABASE MIGRATION;” and U.S. patent application Ser. No. 13/937,970 filed Jul. 9, 2013 by Masterson et al. and entitled “ADVANCED CUSTOMER SUPPORT SERVICES—ADVANCED SUPPORT CLOUD PORTAL”. Each of these applications is hereby incorporated by reference for all purposes. Part BACKGROUND: Migrating a complex database system can be a daunting task. Complex database systems are typically maintained by corporations, governments, and other large-scale entities (collectively referred to as customers) that have a limited ability to tolerate database systems being offline. As such, when mission-critical database systems are to be migrated from a first server system to a second (likely newer and more advanced) server system, the customer is likely desirable of an efficient and timely migration. Conventionally, database migrations are highly personnel intensive, requiring a person (or a team of persons) to identify and use their judgment in figuring out a strategic approach to performing the migration. Oftentimes, such human judgment can be time consuming and result in the implementation of a less than temporally optimal migration scheme. Part SUMMARY: Various arrangements for managing migrations between server systems are presented. In some embodiments, a method for managing migration between server systems is presented. The method may include receiving, by a scheduler computer system, indications of a plurality of migration scripts to be executed during a migration of a database system from a source server system to a target server system. The method may include determining, by the scheduler computer system, an execution order for the plurality of migrations scripts based upon characteristics of a plurality of database objects to be migrated using the plurality of migration scripts and characteristics of the plurality of migration scripts. The method may include initiating, by the scheduler computer system, execution of a first migration script of the plurality of migration scripts according to the determined execution order. The first migration script may cause copying of a database object of the plurality of database objects from the source server system to the target server system. Various embodiments of such a method may include one or more of the following features: The method may include, while the first migration script is being executed, receiving, by the scheduler computer system, an indication of a maximum number of migration scripts permitted to be executed in parallel. The method may include, based on the determined execution order and the maximum number of migration scripts permitted to be executed in parallel, initiating, by the scheduler computer system, execution of a second migration script of the plurality of migration scripts while the first migration script is executing. The method may include, while a subset of the migration scripts of the plurality of migration scripts are being executed and after the first migration script has completed, determining, by the scheduler computer system, an amount of available resources of the target server system exceeds a first threshold amount. The method may include, in response to determining the amount of available resources of the target server system exceeds the first threshold amount, initiating, by the scheduler computer system, an index creation for the database object copied to the target server system based on the first migration script. The index creation may be performed by the target server system. Determining the execution order for the plurality of migrations scripts may be based on execution dependencies of migration scripts of the plurality of migrations scripts on one or more other migration scripts of the plurality of migrations scripts. Additionally or alternatively, embodiments of such a method may include one or more of the following features: The method may include, while a subset of the migration scripts of the plurality of migration scripts are being executed and after the first migration script has completed, determining, by the scheduler computer system, an amount of available resources of the target server system exceeds a first threshold amount. The method may include, based upon the determined execution order, execution of the first migration script being complete, and the amount of available resources of the target server system exceeding the first threshold amount, initiating, by the scheduler computer system, execution of a verification script that causes the target server system to count a number of records in a first database object copied to the target server system. Initiating the execution of the first migration script of the plurality of migration scripts according to the determined execution order may include causing, by the scheduler computer system, modification of a structure of the database object being copied to the target server system as compared to the structure of the database object as stored by the source server system. The modification of the structure may include the database object being copied to the target server system being compressed. Determining the execution order for the plurality of migration scripts may be based upon characteristics of the plurality of database objects to be migrated may include evaluating, by the scheduler computer system, storage sizes of individual database objects of the plurality of database objects; and, based on the evaluated storage sizes of the plurality of database objects, prioritizing, by the scheduler computer system, in the determined execution order the first migration script for the database object due to the database object having a larger storage size than one or more other database objects of the plurality of database objects. Additionally or alternatively, embodiments of such a method may include one or more of the following features: The method may include while a subset of the migration scripts of the plurality of migration scripts are being executed and after the first migration script has completed, determining, by the scheduler computer system, an amount of available resources of the target server system exceeds a first threshold amount but does not exceed a second threshold amount, wherein the second threshold amount is greater than the first threshold amount. The method may include in response to determining the amount of available resources of the target server system exceeds the first threshold amount but not the second threshold amount, initiating, by the scheduler computer system, index creation for the database object copied to the target server system based on the first migration script instead of index creation for a second database object copied to the target server system based on a second migration script. Index generation for the second database object may be more resource intensive than index generation for a first database object. The determined execution order may indicate index generation for the second database object is to be performed before index generation for the first database object. The index creation may be performed by the target server system. The scheduler computer system may be selected from the group consisting of: the target server system; and the source server system. In some embodiments, a system for managing migration between server systems is presented. Such a system may include a source server system, a target server system, and a scheduler computer system. The scheduler computer system may include one or more processors and a memory communicatively coupled with and readable by the one or more processors and having stored therein processor-readable instructions. When executed by the one or more processors, the processor-readable instructions may cause the one or more processors to receive indications of a plurality of migration scripts to be executed during a migration of a database system from the source server system to the target server system. The processor-readable instructions may cause the one or more processors to determine an execution order for the plurality of migrations scripts based upon characteristics of a plurality of database objects to be migrated using the plurality of migration scripts and characteristics of the plurality of migration scripts. The processor-readable instructions may cause the one or more processors to initiate execution of a first migration script of the plurality of migration scripts according to the determined execution order. The first migration script may cause copying of a database object of the plurality of database objects from the source server system to the target server system. Embodiments of such a system may include one or more of the following features: The processor-readable instructions may cause the one or more processors to, while the first migration script is being executed, receive an indication of a maximum number of migration scripts permitted to be executed in parallel. The processor-readable instructions may cause the one or more processors to, based on the determined execution order and the maximum number of migration scripts permitted to be executed in parallel, initiate execution of a second migration script of the plurality of migration scripts while the first migration script is executing. The processor-readable instructions, when executed, further cause the one or more processors of the scheduler computer system to, while a subset of the migration scripts of the plurality of migration scripts are being executed and after the first migration script has completed, determine an amount of available resources of the target server system exceeds a first threshold amount. The processor-readable instructions may cause the one or more processors to, in response to determining the amount of available resources of the target server system exceeds the first threshold amount, initiate an index creation for the database object copied to the target server system based on the first migration script. The index creation may be performed by the target server system. The processor-readable instructions for determining the execution order for the plurality of migrations scripts may be based on execution dependencies of migration scripts of the plurality of migrations scripts on one or more other migration scripts of the plurality of migrations scripts. Additionally or alternatively, embodiments of such a system may include one or more of the following features: The processor-readable instructions may cause the one or more processors to, while a subset of the migration scripts of the plurality of migration scripts are being executed and after the first migration script has completed, determine an amount of available resources of the target server system exceeds a first threshold amount. The processor-readable instructions may cause the one or more processors to, based upon the determined execution order, execution of the first migration script being complete, and the amount of available resources of the target server system exceeding the first threshold amount, initiate execution of a verification script that causes the target server system to count a number of records in a first database object copied to the target server system. The processor-readable instructions for initiating the execution of the first migration script of the plurality of migration scripts according to the determined execution order may include processor-readable instructions, when executed, cause the one or more processors of the scheduler computer system to cause modification of a structure of the database object being copied to the target server system as compared to the structure of the database object as stored by the source server system. Additionally or alternatively, embodiments of such a system may include one or more of the following features: The processor-readable instructions for determining the execution order for the plurality of migration scripts based upon characteristics of the plurality of database objects to be migrated may include processor-readable instructions, when executed, cause the one or more processors of the scheduler computer system to evaluate storage sizes of individual database objects of the plurality of database objects; and based on the evaluated storage sizes of the plurality of database objects, prioritize in the determined execution order the first migration script for the database object due to the database object having a larger storage size than one or more other database objects of the plurality of database objects. The processor-readable instructions may cause the one or more processors to, while a subset of the migration scripts of the plurality of migration scripts are being executed and after the first migration script has completed, determine an amount of available resources of the target server system exceeds a first threshold amount but does not exceed a second threshold amount, wherein the second threshold amount is greater than the first threshold amount. The processor-readable instructions may cause the one or more processors to, in response to determining the amount of available resources of the target server system exceeds the first threshold amount but not the second threshold amount, initiate index creation for the database object copied to the target server system based on the first migration script instead of index creation for a second database object copied to the target server system based on a second migration script. Index generation for the second database object may be more resource intensive than index generation for a first database object. The determined execution order indicates index generation for the second database object may be performed before index generation for the first database object. The index creation may be performed by the target server system. The scheduler computer system may be selected from the group consisting of: the target server system; and the source server system. In some embodiments, a non-transitory processor-readable storage medium for managing migration between server systems is presented. The non-transitory processor-readable storage medium may include processor-readable instructions configured to cause one or more processors to receive indications of a plurality of migration scripts to be executed during a migration of a database system from a source server system to a target server system. The processor-readable instructions may further cause the one or more processors to determine an execution order for the plurality of migrations scripts based upon characteristics of a plurality of database objects to be migrated using the plurality of migration scripts and characteristics of the plurality of migration scripts. The processor-readable instructions may further cause the one or more processors to initiate execution of a first migration script of the plurality of migration scripts according to the determined execution order. The first migration script may cause copying of a database object of the plurality of database objects from the source server system to the target server system. Part DETAILED DESCRIPTION: Rather than having an on-site (or remote) administrator determine the optimal procedure for migrating a database installation from a source server system to a target server system, it may be more effective (e.g., the migration may be performed in a shorter period of time) to have the migration at least partially managed by a scheduler system that is configured to dynamically control migration of the database installation from the source computer system to the target computer system. A “source server system” may refer to a grouping of one or more computer systems that stores and executes a database installation. The source server system may fulfill retrieval, update, and other forms of database queries. A “migration” may refer to moving or copying the database installation to a target server system from the source server system. Therefore, prior to migration, the database installation may only be available on the source server system. Following the migration, the database installation may be present on the target server system and, possibly, still present on the source server system. The “target server system” may refer to a grouping of one or more computer systems that stores the database installation after the migration. The target server system may execute the database installation and fulfill retrieval, update, and other forms of database queries following the migration. A migration can involve multiple types of steps. First, “database objects” (such as tables, etc.) may need to be copied from the source server system to the target server system. Such databases and associated data storage arrangements may range from small to enormous (e.g., hundreds of gigabytes, multiple terabytes, etc.). Copying of the database objects from the source server system to the target server system may be performed while the source application is offline (and, thus, there are no application requests to create, delete, and/or update database entries). In some embodiments, copying may occur while the source server system is online (and, thus, is processing requests and/or updating database entries). As such, modifications to database objects may be logged such that the databases and associated data storage arrangements copied to the target server system may be brought up-to-date. Second, after a database has been copied from the source server system to the target server system, one or more table dependent objects will likely need to be generated for the database copied to the target server system. Such indexes may allow for faster and/or more efficient querying of the database at the target server system. Third, after a database has been copied to the target server system, a customer may expect at least some level of verification to be performed on the database at the target server system to ensure the copy was performed correctly and/or fully. In some embodiments, a row count of the copied database as stored by the target server system is compared with a row count of the database as stored by the source server system. If the row counts match, the customer can be at least assured that no records were lost during the migration. As such, during a migration, at least three major functions may be performed: a copy function, a dependent object generation function, and a verification function. However, it should be understood that in some embodiments, a function may be omitted, such as the verification function. While some of these functions are dependent on other functions, some functions may be performed in parallel. As an example of a dependent function, index generation for a table, coped during the migration processor, to be performed by the target server system may only be performed once the copy of the table to the target server system from the source server system has been completed. However, the copying and index generation of a first table may be performed independently of the copying and index generation of a second table. As such, at least some functions to be performed during a migration may be performed in parallel. A scheduler system may be configured to manage migration from a source server system to a target server system. The scheduler system may be configured to identify an order of copying database objects. The execution order identified by the scheduler system may be based on factors such as the size of the database objects to be migrated, the dependencies of the database objects, the object data types, and/or the application type. The scheduler system may analyze available system resources of the source server system and/or the target server system to schedule functions (e.g., index generation and/or verifications functions). It must be configurable to meet the current configuration of source and target systems (e.g., the way export dump files are made available on the target system by using NFS or a copy method). Further, the scheduler system may be able to take input from an administrator, who may provide various preferences before and during the migration. For example, the administrator may able to dynamically alter the number of migration functions permitted to performed in parallel by the source server system and the target server system during the migration via the scheduler system, to load the available migration resources (e.g., memory resources, processing resources, network bandwidth resources) in an efficient way). Moreover, various types of functions may be scheduled by the scheduler system concurrently. For example, while a copy function between the source server system and the target server system is being performed, more available processing resources may be available at the target server system. The scheduler, if it determines that a sufficient amount of processing resources is available, may schedule execution of index generation by the target server system in parallel for a table which has already been copied to the target server system. FIG. 1 illustrates an embodiment of a system 100 configured to manage and perform a migration between server systems. System 100 may include source server system 110, target server system 120, scheduler computer system 130, network 140, and remote administrator computer system 150. Source server system 110 may represent one or more computer systems. Source server system 110 may store and execute a database installation. Source server system 110 may fulfill retrieval, update, and other forms of database queries and functions. Prior to migration, the database installation may be available on the source server system but not target server system 120. Source server system 110 may include processing resources 112 and storage resources 114. Processing resources 112 may include one or more processors configured to execute multiple processes simultaneously. For example, processing resources 112 are illustrated as executing two migration scripts simultaneously: migration script 113-1 and migration script 113-2. Migration scripts 113 executed by processing resources 112 may be copy scripts configured to copy a database or other storage arrangement from source server system 110 to target server system 120. Execution of migration scripts 113 may be initiated by another system accessible via network 140. Source server system 110 may have storage resources 114 which may represent one or more (non-transitory) computer-readable storage mediums (e.g., hard drives, solid-state drives) which store databases, indexes, and/or other forms of database objects. Some database objects may be copied to target server system 120 as part of a database migration. Typically, a database installation at a source server system 110 may include a large number (e.g., hundreds, thousands, millions) of database objects which may consume a large amount of storage resources. As such, a copy of some database objects from source server system 110 to target server system 120 may take a significant amount of time to perform. In the illustrated embodiment of source server system 110, two migration scripts are being executed by source server system 110. Migration scripts 113 may each result in a particular database object being copied from storage resources 114 to target server system 120. This migration of the database objects is represented by the dotted migration arrow. Migration scripts 113 performed by source server system 110 may be performed in parallel. Target server system 120 may represent one or more computer systems. Target server system 120 may store and execute a database installation after the migration is complete. Typically, target server system 120 may be a faster, newer group of one or more computer systems than source server system 110 (which may be why the migration is being performed). After the migration, source server system 110 may be intended to fulfill retrieval, update, and other forms of database queries. Prior to migration, the database installation may be available on the source server system but not target server system 120. Following migration, the database installation may be available on target server system 120. Target server system 120 may include processing resources 122 and storage resources 124. Processing resources 122 may include one or more processors configured to execute multiple processes simultaneously. For example, processing resources 122 are illustrated as executing three migration scripts simultaneously: migration script 123-1, migration script 123-2, and migration script 123-3. Migration scripts 123 executed by processing resources 122 may be copy scripts configured to receive a database or other storage arrangement from source server system 110 for storage by target server system 120. As such, migration script 113-1 may cause a database object to be copied from source server system 110 while migration script 123-1 serves to receive and create a corresponding database object at target server system 120. Based on configuration of the scheduler system and/or of the migration scripts, one or more database objects copied to the target server system may be modified as compared to the same database object as stored by the source server system. For example, the created database object at the target server system may be compressed, while the corresponding database object stored by source server system 110 was uncompressed. In some embodiments, one or more database objects as stored by target server system 120 may be structured differently than the corresponding database object stored by source server system 110. The processing resources 122 of target server system 120 may execute migration scripts that cause index generation. An index may allow a database stored by target server system to be accessed more efficiently (e.g., on the basis of time and/or usage of processing resources). Once a table has been copied from source server system 110 to target server system 120, an index may be created for this table. As such, only database table objects may be copied from source server system 110 to target server system 120, such as databases. Other forms of database objects, such as database indexes, primary keys, referential constraints, and/or views may be created by the target server system 120 rather than be copied from source server system 110. In the illustrated embodiment of system 100, target server system 120 is executing a migration script 123-3 that is creating an index file for a table stored by storage resources 124. Storage resources 124 may represent one or more (non-transitory) computer-readable storage mediums of target server system 120, such as hard drives and solid state drives. Storage resources 124 may store databases and other database objects copied from storage resources 114 of source server system 110. Storage resources 124 may additionally store database objects, such as a database indexes, created by target server system 120. Additionally, processing resources 122 may perform migration scripts that confirm that copied database objects stored by target server system 120 match the source database object stored by source server system 110. Such a verification migration script may involve a row count being performed on both database objects to determine if the counts match (individual data element comparisons may not be performed). Migration scripts 123 performed by target server system 120 may be performed in parallel. Network 140 may include one or more networks that can be used for communication between source server system 110 and target server system 120. Network 140 may include one or more public networks, such as the Internet and/or one or more private networks such as a corporate intranet. In some embodiments, a direct connection may be present between source server system 110 and target server system 120 to facilitate faster data transfers. Network 140 may also permit communication between source server system 110, target server system 120, a scheduler computer system 130, and remote administrator computer system 150. Scheduler computer system 130 may represent a computer system separate from source server system 110 and target server system 120. Alternatively, functions of scheduler computer system 130 may be performed by either source server system 110 or target server system 120. For example, in some embodiments, a scheduler may be executed by target server system 120. Scheduler computer system 130 may be configured to control when migration scripts are executed by source server system 110 and target server system 120. Given a listing of migration scripts to be executed, scheduler computer system 130 may be configured to determine an order of execution to optimize the migration from source server system 110 to target server system 120. Scheduler computer system 130 may be configured to query source server system 110 and/or target server system 120 to determine the amount of processing resources available at each server system. Based on an assessment of processing resources available, the number and/or which migration scripts are executed by source server system 110 and/or target server system 120 may be varied. In some embodiments, an administrator who is managing the migration may provide input directly to scheduler computer system 130. Such input may occur during the migration; therefore, the administrator may be able to modify characteristics of the migration process while the migration is in progress. The administrator may be permitted to define particular parameters that govern scheduler computer system 130. For instance, the administrator may define a maximum number of migration scripts which can be executed simultaneously by source server system 110 and/or target server system 120. In other embodiments, rather than the administrator providing input directly to scheduler computer system 130, the administrator may use remote administrator computer system 150 to provide input to scheduler computer system 130. Therefore, an administrator may be able to perform the migration in a cloud-based arrangement. The scheduler computer system 130 and/or remote administrator computer system 150 may be remotely located from source server system 110 and/or target server system 120. Therefore, an administrator, who may be hired on a contract basis, such as from the company that produced the database software, may be able to perform a cloud-based migration of the database installation from source server system 110 to target server system 120. FIG. 2 illustrates an embodiment of a support cloud platform 200. The platform may be used to implement a service, such as a migration from a customer's source server system to the customer's target server system. Services may be designed, made available for deployment, deployed to a customer, and monitored using the platform. The customer data center 202 may include one or more target systems 212, 214 (one of which may be the customer's source server system, the other being the customer's target server system) that may be the target of the services provided by the platform. The target systems may be servers, computers, rack systems, and the like that run or execute a database and/or other database software used by a customer. A target system may be a hardware or software entity that can have service delivered and may be a host, database, web logic service, and/or the like. In the customer data center 202, the target systems 212, 214 may be managed by an administrator local to the customer data center 202. The administrator may have physical access to the target systems 212, 214. The support cloud platform 200, may provide for the administration and other services of the target systems via a remote interface from a remote location. As such, support cloud platform 200 may serve as a platform for how remote administrator computer system 150 of FIG. 1, interacts with the migration from source server system 110 to target server system 120. A gateway 210, located on the customer data center 202 provides remote access to the customer data center 202 and one or more target systems 212, 214. The gateway 210 may be a hardware or virtual software appliance installed at the customer data center. The gateway 210 connects to a production cloud 204 of a service provider via a secure connection using a communication module 206 over a network 232 (which may represent network 140 of FIG. 1). The gateway 210 may optionally have an interface module 208 allowing control of the interactions of gateway 210 to the production cloud 204 of the service provider. Services may be generated and developed using a common service development framework of the platform. The common service development framework may include a service design 230, delivery engineering 228, and engineering infrastructure 226 modules. The common service development framework may leverage common components that can be used throughout the delivery process (manual and/or automated), and may enable the efficient design, development, testing and release of a service. The common service development framework of the platform enables at least partial automation of the development of a service. The platform enables delivery engineers to automate the service they are developing and implementing. In some embodiments, the development of services may be automated or simplified with the use of reusable components. For example, many of the same deployment, execution, and error handling function used in the services may be designed as reusable components. The components may be reused in many services allowing the design and coding of the service to be focused on the new core functionality of the service. Using the platform, services may be designed and implemented in one or more central locations. A centralized service design and development platform enables a hierarchical and structured service design with reusable components and modules. The development of a service may be, at least in part, automated since a large portion of the components of a service may assembled from existing reusable components. After the services are designed, developed, and tested, they may be stored at the production cloud 204. For example, a service may include modification replicator 116 of FIG. 1, which may be installed at the source server system of the customer ahead of an online migration. Similarly, the functionality of scheduler computer system 130 of FIG. 1 may be implemented as a service that is deployed from production cloud 204. The production cloud 204 may include a library of services 222 and a content library 224. The services and content may be deployed from the production cloud 204 to one or more target systems 212, 214 at a customer data center 202. The deployment, monitoring, and the like of services may be arranged with interaction from the portal 218 and commerce module 220 at the production cloud 204 and the gateway 210 and an interface module 208 at the customer data center 202 via the communication modules 206, 216. The design, deployment and monitoring of the service may be performed remotely from production cloud without the need of an administrator or engineer at the customer data center 202. The portal 218 of the platform may provide for remote control and administration of services, control of deployment, and analysis of results. The platform of FIG. 2 may be used to develop, deploy and manage, services for the customer data center 202 and target systems 212, 214. A gateway 210 has access to the target systems 212, 214. Services, in the forms of software, scripts, functions, and the like, may be downloaded from the production cloud 204. The commerce module 220 and the portal for the production cloud 204 provide an interface, selection tools, monitoring tools, for selecting the services, and monitoring the services to be deployed in the customer data center 202. An administrator at the customer data center 202 may view, select, and monitor the services using the portal 218 and commerce module 220. The customer may access the portal 218 and commerce module 220 using interface module 208 at the customer data center 202. The interface module may have a direct or an indirect access to the portal 218 and the commerce module via the communication module 206. For example, using the support cloud platform 200, a service may be selected using the commerce module 220. The commerce module 220 may be accessed using the interface module 208. Once a service is selected and configured for the target systems 212, 214, the service may be deployed from the production cloud 204 to the customer data center 202 via the gateway 210. The gateway may deploy the service on to the target systems. The gateway 210 may be used to gather data statistics, monitor services, and receive system information about the customer data center and the target systems. The data may be processed, analyzed, and transmitted to the production cloud. The data may be used to suggest or deploy services to the customer, present statistics or metrics of the customer's target servers using the portal 218. Therefore, without an administrator coming to the customer's site to access the source server system and target server system in person, an administrator may be able to perform a migration from the source server system to the target server system. FIG. 3 illustrates an embodiment of a scheduler computer system 300 configured to manage a migration between two (or more) server systems. Scheduler computer system 300 may represent scheduler computer system 130 of FIG. 1. Scheduler computer system 300 may also be implemented in a system other than the arrangement of system 100 of FIG. 1. Scheduler computer system 300 may be implemented using one or more instances of computer system 700 of FIG. 7. Scheduler computer system 300 may include: migration script analysis engine 310, migration script storage arrangement 320, execution order storage arrangement 330, scheduling engine 340, resource query engine 350 and/or administrator input interface 360. Each of these components may be implemented using (non-transitory) computer-readable storage mediums and/or processors. Functions performed by these components may be implemented using hardware, firmware, and/or software executed by one or more computer systems. As such, functions of multiple components may be performed by a single processor. Alternatively, functions of a component may be executed by multiple processors. Migration script storage arrangement 320 may store migration scripts created for use in migrating a source server system to a target server system, such as illustrated in FIG. 1. While FIG. 3 illustrates migration script storage arrangement 320 stored by scheduler computer system 300, in other embodiments, migration script storage arrangement 320 may be stored remotely, such as by target server system, source server system, and/or by some other computer system. At a minimum, scheduler computer system 300 may have access to migration script storage arrangement 320 (which may be located elsewhere). Execution of all of the migration scripts of migration script storage arrangement 320 may be necessary to perform the migration from the source server system to the target server system. Migration script storage arrangement 320 may contain migration scripts which perform copy functions, index generation functions, and/or verification functions. Other functions are additionally possible. Migration script analysis engine 310 may analyze the stored migration scripts of migration script storage arrangement 320 and/or the database objects to which the migration scripts refer. Migration script analysis engine 310 may determine a more optimal order in which to perform the migration scripts to minimize the amount of time necessary to perform the migration. The time needed to migrate (e.g., copy and create dependent objects) a database object (that is a database table and its dependent objects (e.g. indexes, constraint definitions), depends on the database object size and the data types used. Depending on the used data types, different migration methods can be used to minimize the migration time for a particular table. Migration script analysis engine 310 may analyze the size of the database objects to be transferred. In at least some embodiments, it may be efficient to transfer large databases (or other database objects) near the beginning of a migration, therefore preventing the end of the migration process from getting delayed, waiting for the large database to transfer (and then performing functions dependent on the transfer of that database). Further, the verification of the database may only be performed once the database has been transferred. As such, migration script analysis engine 310 may determine which databases and/or other database objects are the largest and may prioritize their migration from the source server system to the target server system such that the transfer occurs earlier during the migration. Migration script analysis engine 310 may also analyze dependencies among migration scripts. Migration script analysis engine 310 may ensure that migration scripts which require another migration script to be performed first are initialized in an acceptable order. For example, migration script analysis engine 310 may ensure that a copy function for a database is performed before an index generation function and/or verification function for the database is performed. Migration script analysis engine 310 may enforce various other rules that have been predefined in scheduler computer system 300. For instance, administrators who have performed many migrations may configure various rules that migration script analysis engine 310 follows when determining an execution order of migration scripts. For example, based on the object size and data types used by a particular table, the administrator can determine the migration method to be used for this table. Based upon the chosen migration method, the analysis software will determine the order of execution automatically. For a table, one or more of the following rules may apply: 1) Copy the table data to the target system. 2) If a datapump (or other form of server based bulk data movement infrastructure) or export function is used, dump files may be required to be made available on the target. Therefore, a copy process may be needed. 3) If datapump is used and table compression is active, an SQL script must be executed on the target server system to create a compressed table before starting the import from the source server system. 4) Once the table is loaded, the row count verification on the source server system can be started. 5) In parallel with rule four, the index/PK (primary key) constraint creation can be started for this table on the target server system. 6) Once the first index is created at the target server system, the row count verification can be started on the target server system in parallel. 7) Once all indexes for a table have been created, table/index statistics from the source system can be imported for this table. 8) Once all tables are loaded to the target server system, any outstanding foreign key definitions can be created at the target server system. The determined order of execution for the migration scripts may be stored in execution order storage arrangement 330. Execution order storage arrangement 330 may indicate an order that migration script analysis engine 310 has determined to be preferable for performing the migration quickly. Execution order storage arrangement 330 may also store data that indicates dependencies as to which migration scripts can and/or cannot be performed before other migration scripts have completed. While execution order storage arrangement 330 stores a preferable order for performance of migration scripts, the actual execution order of scripts may be dynamically modified by scheduler computer system 300 based on conditions during the migration as determined. Further, an administrator may reorder initialization of the execution of migration scripts during the migration (e.g., while migration scripts are being executed). Resource query engine 350 may periodically or sporadically determine the amount of processing resources available at the source server system and/or the target server system. Based on the amount of resources available, the execution order of migration scripts may be altered from the previously determined execution order. For example, if a target server system has a significant amount of available processing resources but the source server system has few available processing resources and/or the bandwidth between the source server system and the target server system is already operating near capacity, a migration script which consumes significant processing resources of the target server system (but not the source server system) may be initiated. For instance, execution of an index generation migration script for a table at the target server system may be initiated. Generation of which index may be contingent on the amount of processing resources available and/or an estimation of the amount of time the processing resources are expected to remain available. For instance, if a smaller amount of processing resources is available, an index for a smaller table may be generated. If a larger amount of processing resources is available, an index for a larger table may be generated. The amount of processing resources required to be available for such a migration script to be initiated may be contingent on predefined thresholds stored by scheduler computer system 300. In some embodiments, resource query engine 350 may periodically poll the source server system and/or the target server system. In other embodiments, the source server system and/or the target server system may be polled on request by scheduling engine 340. Scheduling engine 340 may be configured to determine the timing for when migration scripts from migration script storage arrangement 320 are to be initialized. When initialized, a migration script may be executed by the source server system and/or the target server system. Scheduling engine 340 may determine the timing for initialization of the execution of a migration script based on the execution order previously determined by migration script analysis engine 310, the amount of resources available at the target server system and/or source server system (as determined by resource query engine 350), and/or parameters defined by an administrator, such as the maximum number of migration scripts permitted to be executed by the source server system and/or the target server system simultaneously. Therefore, while scheduling engine 340 may use the execution order in determining the order in which to initialize migration scripts, other factors may affect the actual ordering of initialization of migration scripts. Administrator input interface 360 may permit an administrator to provide input to scheduler computer system 300 and/or receive feedback on the performance of the migration. Administrator input interface 360 may allow an administrator to interact locally with scheduler computer system 300 and/or interact with scheduler computer system 300 remotely, such as via a cloud-based gateway and portal. Administrator input interface 360 may permit the administrator to define parameters for scheduler computer system 300 prior to the scheduler computer system creating an execution order and scheduler computer system 300 initiating migration scripts for execution by the source server system and/or the target server system. Administrator input interface 360 may also permit an administrator to dynamically modify the scheduler computer system while scheduling engine 340 is determining which migration script should be executed by the source server system and/or the target server system. For example, while the migration is in progress, the administrator may modify the maximum number of migration scripts permitted to be performed in parallel by the source server system. In response to such input provided via administrator input interface 360, scheduler computer system 300 may not schedule more than the maximum number of migration scripts to be executed simultaneously by the source server system. FIG. 4 illustrates an embodiment 400 of a visual representation of concurrent migration script scheduling as initiated by a scheduler computer system. For example, the scheduler computer system that scheduled the migration scripts of embodiment 400 may be scheduler computer system 300 of FIG. 3 and/or scheduler computer system 130 of FIG. 1. Embodiment 400 illustrates migration copy scripts 410, migration index generation scripts 420, and migration verification scripts 430 being executed during partially overlapping time periods. Migration copy scripts 410 may be executed by the source server system and the target server system. For example, a migration copy script of migration copy scripts 410 may be executed by the source server system to retrieve and transmit a particular database object to the target server system. A migration copy script of migration copy scripts 410 may be executed by the target server system to receive and store the database object. At a given time, multiple migration copy scripts 410 may be performed simultaneously by the source server system and/or the target server system. Migration index generation scripts 420 may be executed by the target server system to generate indexes for received tables. For example, a migration copy script 410-1 of migration copy scripts 410 may be executed to retrieve, transmit, and store a particular database object by the target server system. Since index generation may be dependent on the associated table already having been copied, migration index generation script 420-1 may be initiated at the target server system sometime after migration copy script 410-1 is complete. At a given
{'bibliographic_information': "{'country': 'US', 'doc-number': '15789049', 'kind': 'B2', 'date': '20171020', 'disclaimer_text': 'This patent is subject to a terminal disclaimer.', 'invention_title': 'Dynamic migration script management'}", 'source_file': './grant/2019/ipg190402.xml', 'source_data': 'USPTO-Grant'}