Patent Application
20100262632
A hosted application is a software application where the software resides on servers that are accessed through a wide-area network, such as the Internet, rather than more traditional software that is installed on a local server or on individual client computers. Hosted applications may also be known as Internet-applications, application service providers (“ASPs”), web-based applications, or on-line applications. Hosted applications are commonly utilized concurrently by multiple subscriber organizations, called “tenants.”
Some hosted applications utilize a multi-tier architecture in which the middle tier that performs the application logic is separated from the database tier where application and tenant data is stored. In many cases, the database tier is shared among all of the tenants. Use of a shared database tier in this manner is problematic, however, because a scheduled or unscheduled database outage in such a system will affect all of the tenants simultaneously. Moreover, because all tenants share the same database tier, application performance for all of the tenants may be significantly reduced if just one tenant places an excessive load on the database, such as when the tenant desires to migrate its data to a different deployment. Reduced performance may be unacceptable to the tenants of such a system. Additionally, when a single database is utilized for all of the tenants of a hosted application, it may be difficult for a tenant to customize the schema that is utilized to store the database.
Other hosted applications utilize a multi-tier architecture in which each tenant utilizes a middle tier and a database tier that are maintained separately from all other tenants. This type of architecture may be implemented, for instance, by providing each tenant with a virtual server computer for hosting the middle tier and the database tier. This type of architecture allows outages to be confined to a single tenant or a small group of tenants, and reduces the possibility that an excessive load by one tenant will impact application performance for other tenants. This type of architecture, however, suffers from several other significant drawbacks. In particular, it can be complex and expensive to operationally maintain the separate operating system and application installation on the virtual server computer provided for each hosted tenant. Moreover, allocated hardware resources may remain unused by tenants that cannot utilize all of the processing and storage capabilities of a dedicated virtual server computer.
Customer relationship management data is used by many companies and other organizations in order to assist them in managing the relationships they have with their customers, and to consistently evaluate and improve customer service. Many times, especially when a company or other organization is relatively small, it makes sense to deploy customer relationship management (CRM) software according to a service model in which the company or organization uses the software that is hosted on-line by a remote host, as described above. In this way, the company or organization (the tenant) is able to share the cost associated with hosting the software with other businesses or organizations (other tenants), thereby reducing their costs.
However, as the company or organization grows, so does its CRM application needs. Under this type of expansion scenario, customers may prefer to transition from the service model to an on-premise model in which the CRM software (and corresponding data) is managed by the customer, itself, on the customer's local site.
It is currently difficult to transition from a CRM application in the hosted, service model to one in the on-premise model because this often involves the migration of large amounts of customer relations data from the hosting environment to the customer's local computing environment. Such a transition can affect the day-to-day use of the CRM system and result in business disruption, possible data loss, and the requirement for user training and experience with the local version of the application.
The discussion above is merely provided for general background information and is not intended to be used as an aid in determining the scope of the claimed subject matter.
A customer can request migration of its data from a multi-tenant hosting environment to a local environment. The customer's data is pulled from the multi-tenant hosting environment and scrubbed so that it is compatible with a local version of the application previously hosted in the multi-tenant hosting environment. The data is made available to the customer at a secure location in the hosting environment. The customer retrieves the data, after proper authentication, to its local data store, and then imports the data into the local version of the application. Users of the local version of the application are then mapped from previous multi-jurisdictional identifiers to local user identifiers in the application.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended that this Summary be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure.
Prior to discussing the migration of data from a hosted deployment of an application to an on-premise deployment of the application, in detail, one embodiment of a hosted, multi-tenant architecture will first be described.
Through the use of the system 100 shown in
The CRM functionality provided by the CRM application 106 may be accessed through the use of a web browser application 114 executing on a client computer, such as the CRM client computer 104. The CRM application 106 includes a web user interface (“UI”) module 108 for exposing a web-compatible network interface. In this manner, the CRM client computer 104 can be utilized to access functionality provided by the on-line version (or hosted version) of the CRM application 106 for creating and viewing customer information, for communicating with customers via the CRM application 106, and for performing other CRM-related functions.
According to embodiments presented herein, the CRM application 106 also includes a business object platform 110. The business object platform 110 is a software platform for executing software components that perform the actual business processing for the CRM application 106. The business object platform 110 operates in conjunction with the web UT module 108 to make this functionality accessible through a web interface. Aspects of the functionality provided by the CRM application 106 may also be accessed through a plug-in to a personal information manager (“PIM”) application 116. In one embodiment, a plug-in executing within the PIM application 116 communicates directly with the business object platform 110 to enable this functionality. Of course, other functionality can be made available in other ways as well.
As shown in
Through the use of the database server application 112, the CRM application 106 is operative to maintain several databases. In particular, the CRM application 106 maintains a shared configuration database 122. As will be described in greater detail herein, the CRM application 106 utilizes the shared configuration database 122 to store global system-level information and data that is shared by the tenants. For instance, according to embodiments, the shared configuration database 122 may be utilized to store information about tenants, such as their name and contact information, information about which tenant particular users are members of, and information mapping authentication data to a specific user. In one implementation presented herein, the shared configuration database 122 is also utilized to store data defining a scale group to which each tenant hosted by the CRM application 106 has been assigned.
The CRM application 106 also maintains the unshared organization databases 120A-120N. The unshared organization databases 120A-120N are utilized by the on-line CRM application 106 to store private, unshared data for the tenants. Each unshared organization database 120A-120N is associated with a particular tenant and its contents are inaccessible to the other tenants. Accordingly, each unshared organization database 120A-120N is utilized to store private tenant data for the associated tenant. Each unshared organization database 120A-120N may also be utilized to store customizations to the on-line CRM application 106 made by the associated tenant including, but not limited to, customized entities, attributes, relationships, forms, views, code-level extensibility plug-ins, and any other type of customization to the CRM application 106. It should be appreciated that other types of databases and database schema may be utilized to store the global system-level information and the tenant data according to other embodiments.
In one implementation, each scale group 202A-202N includes a shared middle tier and a database tier for supporting the tenants assigned to the scale group. Scale group Internet-facing servers 210 implement the middle tier by executing the on-line CRM application 106, while scale group database servers 214 implement the database tier by executing the database server application 112. One or more scale group utility servers 212 are also provided within each scale group 202A-202N for performing utility functions, such as reporting services, load balancing, provisioning, configuration, statistics, and others. Each scale group may also include its own configuration database that is private to the scale group but shared among all of the tenants of the scale group. As will be described in greater detail below, the servers in each of the scale groups 202A-202N may be assigned to one or more roles for performing these functions.
When a new tenant is provisioned within the system 200, the tenant is assigned to one of the scale groups 202A-202N. At this time, one of the scale group database servers 214 in the assigned scale group creates a private, unshared database 120 for the tenant. In this manner, the private, unshared database 120 for the new tenant is created and stored in the assigned scale group 202. An association, or mapping, between the tenant and the assigned scale group 202 is also created in the shared configuration database 122.
As shown in
Network client requests to access the on-line (or hosted) application 106 are received at the site-wide Internet-facing servers 206. In response to receiving such requests, the shared configuration database 122 is consulted to locate the scale group 202A-202N hosting the private, unshared database 120 for the tenant making the request. Once the appropriate scale group 202A-202N has been located, the incoming request is redirected to the scale group Internet-facing servers 210 in the identified scale group 202A-202N for processing.
Servers assigned to the administration role 214D are configured for performing administrative tasks for manipulating the system 200. For example, a server assigned to the administration role 214D may be configured to execute commands to create scale groups, move tenants between scale groups, and to provision tenants for testing, support, or monitoring purposes. Servers assigned to the router role 214E are configured to redirect certain actions to an appropriate scale group 202. For instance, a server assigned to the router role 214E may be configured to route a job to provision a new tenant, upgrade the data for a tenant, retrieve data for a tenant for migration to a different deployment or to delete a tenant from the appropriate scale group 202. Other types of actions may be routed in a similar manner. It should be appreciated that the site-wide utility servers 208 may be assigned to one or more of the roles shown in
As also shown in
Despite the advantages of a hosted multi-tenant deployment, it may be desirable for organization or company to migrate its data from the hosted environment of system 100 to a local site such as CRM client computer 104, so that the CRM application is locally run and all the data is locally stored and maintained. This is illustrated in
As discussed above, it may be desirable for an organization to migrate its data from unshared multi-tenant data 120 on CRM hosting site 102 to an on-premise deployment of the CRM application on CRM client computer 104. This is shown at the bottom half of
The hosting agent then authenticates the customer. This can also be done in a variety of different ways. For instance, the hosting agent may request certain information from the customer, such as a user identification and password. The hosting agent may also request information indicative of the fact that the customer has purchased an on-premise license for the on-premise version of the CRM application to which the customer data is being migrated. Similarly, the hosting agent may ensure that the customer that is requesting the data migration is also verified within the on-line system as being the entity that is in charge of the billing or that is otherwise in charge of (or the contact person for) the on-line account maintenance for the on-line version of the CRM application. Of course, a wide variety of other ways can be used to authenticate the customer. Having the hosting agent authenticate the customer making the request is indicated by block 387 in
The hosting agent then confirms that the migration to the on-premise deployment has been requested and authenticated. This can also be done using electronic messaging, such as electronic mail, or other type of automated messaging, or it can be done by providing a confirmation code over the telephone from the hosting agent to a customer. This is indicated by block 389 in
Once the hosting agent has received, authenticated, and confirmed the customer's request to migrate data to the on-premise deployment, the hosting agent schedules the data migration. In doing so, the hosting agent accesses the current data migration requests that are currently scheduled for the present week. These may be kept in a scheduling system on the site-wide servers or elsewhere. If a threshold number of migrations have already been scheduled, then the hosting agent pushes the data migration to a subsequent week in which the threshold number of data migrations have not yet been scheduled. Scheduling the data migration to occur during a week that has sufficient availability is done in order to ensure that the data will be available to the customer, when promised. Once the data migration has been scheduled, notice to that effect is again sent to the customer, either in an automated way, electronically, or by personal contact, or in any other desired way. Scheduling the data migration to the on-premise deployment is indicated by block 391 in
The customer data is then retrieved from the unshared multi-tenant data component 120 and placed in an internal, secure, file share component, such as component 121 shown in
The data in the internal file share component 121 is then submitted to scrubbing tool 310 where it is scrubbed so that it is in proper form to be downloaded and imported into the on-premise deployment. Scrubbing tool 310 will vary, depending on the particular application, and depending on the slight variances between the on-line version of the CRM application and the on-premise version of the CRM application. For instance, the data may be in a slightly different form when used in the on-line version, as opposed to when it is used in the on-premise version. Scrubbing tool 310 thus makes whatever deletions, additions, or transformations are required to place the data in proper form for the on-premise deployment. Again, it will be noted that since the code base of the two versions of the CRM application (the on-line version and the on-premise version) are substantially the same, scrubbing tool 310 will likely be making only relatively minor changes to the data.
Some such changes will include, by way of example, preserving data that was generated using on-line search features, but removing the on-line search features, themselves, so that they cannot be used in the on-premise version of the CRM application. In this way, all of the underlying data for the customer is preserved, but some of the features may be removed or added, or modified, given the differences between the on-line version of the CRM application and the on-premise version. Scrubbing the data is indicated by block 403 in
Once the data has been scrubbed, it is placed in a solution packet in the secure file server data store 314 on secure file server 312. The solution packet can also optionally include additional files which may be needed by the customer in order to download and import the data into the on-premise version of the CRM application. Placing the scrubbed customer data and other needed files in the solution packet on the secure file server is indicated by block 405 in
The host then notifies the customer that the solution packet is available, and provides the location of the solution packet and instructions needed to download the data onto the CRM client computer 102, for deployment in the on-premise version. This is indicated by block 407 in
Next, the host determines whether the on-premise migration requested by the customer is complete. This is indicated at block 409. The on-premise migration may not be complete for a variety of reasons. For instance, in one illustrative embodiment, the customer may desire to perform a number of test migrations prior to migrating the final version of its CRM data to the CRM client computer 102. In that case, the host may allow the customer to request its data a plurality, but limited, number of times. In one exemplary embodiment, the host may allow the customer to request a data migration three times, for instance. Then, when the customer requests data from the host, the hosting agent notes the number of requests that have been made. If the number of requests is less than three, then the hosting agent, indicates that the customer can request its data an additional number of times in the future, when the hosting agent confirms to the customer that the request has been made. For instance, if this is the first request for data migration from the customer, then when the hosting agent confirms the request, the hosting agent also indicates that the customer can request its data two more times. Thus, at block 409, the hosting agent determines that the migration is not complete, but that this is only a test data migration.
This is also illustrated in
It should also be noted that a customer can use a hybrid system in which some of its users are using the on-line version of the CRM application and some are using the on-premise version. In that case, only certain user subscriptions are deleted at block 411 from the on-line version. Some user subscriptions to the on-line version will be maintained. Then, the user is responsible for maintaining synchronicity between the data in the unshared multi-tenant hosting environment at CRM hosting site 102 and the data in the on-premise environment on CRM client computer 102. It may be desirable to maintain a hybrid system so that some users can maintain the features associated with the on-line version of the CRM application, yet not all users maintain those features. Therefore, the client need not pay the subscription price for all of its users. This, of course, is optional and the customer need not maintain any subscriptions to the on-line version of the CRM application.
After the data has been retrieved and scrubbed at the hosting site, and placed in the secure file server, the customer receives notification that the data and other necessary files are available, along with the location of the data and files and instructions for downloading the data and files. This is indicated by block 504 in
The customer then retrieves the scrubbed data and files stored in data store 314 at the CRM hosting site 102. The customer can do this by using a conventional download component 330 that downloads the CRM data, through database server 318, into data store 316. The customer downloads other application components or files into the on-premise CRM application 334 on the application server 320. For instance, there may be bug fixes or other updates to the on-premise CRM application that the hosting agent places in the secure file server 312 for download by the customer. In that case, download component 330 downloads those files to the CRM application on the application server 320. Retrieving and saving the data and files to the customer data store 316 and application server 320 is indicated by block 508 in
The customer then uses import tool 332 to import the downloaded data into the CRM application, thus populating data structures for use by the CRM application. In one embodiment, the import tool 332 may be part of the CRM application 334 or separate from it. In either case, the import tool 332 may illustratively provide a number of dialog boxes which allow the customer to import the data into the application. This is indicated by block 510 in
The customer then maps the users of the on-line version of the CRM application to users of the on-premise version of the CRM application. In one illustrative embodiment, this is also enabled by the import tool 332, which displays a number of dialog boxes that allow the customer to map the users, as desired. For instance, in the on-line version of the CRM application, users may need to be identified by a multi-jurisdictional passport type of identification. One such form of identification is referred to as a Windows Live ID which uniquely identifies a user among multiple jurisdictions or environments on-line. In migrating to an on-premise application, the customer may desire to map the users to local user identifications instead of the multi-jurisdictional identifiers. One example of a local identifier is an Active Directory identification. Mapping the on-line user IDs to local user IDs is indicated by block 512 in
The customer then determines whether the migration has been finalized. For instance, if the data migration has been a migration of one of the test copies of data, then the migration is not yet complete, and processing reverts to block 500, where the user can again request its data for migration to the on-premise deployment. Alternatively, however, if this was the final data migration, and the migration to the on-premise deployment has been completed, then the customer can cancel user subscriptions to the hosted, on-line application for some or all users at the customer site. As discussed above, the user may wish to have an entirely on-premise system, in which case all user subscriptions to the on-line version of the application will be canceled. However, the user may wish to maintain either a dual system, or a hybrid system, in which some or all of its users maintain their subscriptions to the on-line version of the application, but some or all of whom also have local access to the on-premise version of the application. Determining whether the migration is finalized is indicated by block 514, and canceling subscriptions for some or all of the users of the on-line version of the application is indicated by block 516 in
This type of data migration allows a customer of an on-line CRM deployment to switch to an on-premise deployment very quickly and easily, with no loss of data and substantially no interruption in service. It also allows the customer to schedule both test and final data migrations. The customer also controls mapping of on-line users to the local system.
The invention is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
The invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
With reference to
Computer 710 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by computer 710 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer 710. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.
The system memory 730 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 731 and random access memory (RAM) 732. A basic input/output system 733 (BIOS), containing the basic routines that help to transfer information between elements within computer 710, such as during start-up, is typically stored in ROM 731. RAM 732 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 720. By way of example, and not limitation,
The computer 710 may also include other removable/non-removable volatile/nonvolatile computer storage media. By way of example only,
The drives and their associated computer storage media discussed above and illustrated in
A user may enter commands and information into the computer 710 through input devices such as a keyboard 762, a microphone 763, and a pointing device 761, such as a mouse, trackball or touch pad. Other input devices (not shown) may include a joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 720 through a user input interface 760 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A monitor 791 or other type of display device is also connected to the system bus 721 via an interface, such as a video interface 790. In addition to the monitor, computers may also include other peripheral output devices such as speakers 797 and printer 796, which may be connected through an output peripheral interface 795.
The computer 710 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 780. The remote computer 780 may be a personal computer, a hand-held device, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 710. The logical connections depicted in
When used in a LAN networking environment, the computer 710 is connected to the LAN 771 through a network interface or adapter 770. When used in a WAN networking environment, the computer 410 typically includes a modem 472 or other means for establishing communications over the WAN 773, such as the Internet. The modem 772, which may be internal or external, may be connected to the system bus 721 via the user input interface 760, or other appropriate mechanism. In a networked environment, program modules depicted relative to the computer 710, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
