Invented by Chinni; Manjunath, Kandula; Veera Venkata Naga Rama Satyam, Luo; Jiangbin

Moving data between clouds is never easy, especially when the databases in each cloud follow different rules for updates. If you’ve ever tried to move a database from a public cloud to a government-secured cloud—or the other way around—you already know about the headaches caused by mismatched database structures, called “schemas.” A new patent application offers a clever way to solve this issue. Today, we’ll explain the context, the science, and the unique ideas behind this technology, so you can see how it could change the way companies handle cloud data migrations.

Background and Market Context

Cloud computing has changed how we store and use data. Companies now run their software and keep their databases on many different clouds. Some clouds are public, like Amazon Web Services (AWS) or Google Cloud, where anyone can rent space and power. Others, like those approved by the U.S. government’s FedRAMP program, are private and have extra rules to keep data safe and secure.

Each cloud has its own way of updating the database structure—the “schema.” Think of a schema as the blueprint of a database. It tells the computer what kind of information is stored and how it fits together. Every so often, companies update this blueprint, maybe to add new features or make things faster. But here’s the problem: public clouds might update their schemas every week, while government clouds update them only every few months. This creates a mismatch.

When companies need to move their data from one cloud to another, they often run into trouble. If the schema in the source cloud is newer than the one in the destination, the data might not fit. If the schema in the destination is newer, the old data might not have all the pieces the new system expects. This is a big problem for businesses that need to switch clouds, upgrade their systems, or meet new security rules.

Until now, handling these schema mismatches has been slow, risky, and expensive. Companies sometimes have to stop all work during the move, risking lost productivity and unhappy customers. Sometimes, the data gets messed up or features break. If you’re a company that needs to move from a fast-moving public cloud to a slower, but more secure, private cloud, you’re caught between a rock and a hard place.

There are more reasons why this problem matters. The move to cloud computing is only speeding up. More companies want to use the newest tools, but they also need to keep their data safe. Government rules are getting stricter, meaning more companies need to move their data to special, secure clouds. At the same time, customers expect apps to be available 24/7. This means companies can’t afford long downtimes or broken features during data moves. The market is hungry for a better way to handle database migrations—one that’s fast, safe, and easy.

That’s where this new patent application steps in. It describes a method that lets companies move databases between clouds with different schema update rules, all without the usual headaches. By using an extra, temporary stop—the “intermediate” cloud—this method lets the schemas catch up to each other before the final move. It promises less risk, less downtime, and smoother migrations. Let’s see how it all works, and why it’s so important.

Scientific Rationale and Prior Art

To understand why this new idea matters, let’s start with some basics. A database schema is the plan that tells the computer what kind of information is stored in the database and how it is organized. When you want to change how your app works, maybe to add a new feature or make things safer, you often need to update this schema. In the world of cloud computing, these updates happen on a schedule. The “release cadence” is just a fancy way of saying how often these updates happen.

Imagine you have two clouds. In one cloud, the schema gets updated every week. In the other, it only gets updated every few months. If you try to move a database from the fast-updating cloud to the slow one, the schemas won’t match. This means the data might not fit, or some features might not work. This is called a schema mismatch, and it’s a common problem.

For years, people have tried to solve this with different tricks and tools. Sometimes, they freeze all changes in the database during the move, so nothing goes out of sync. Other times, they write special scripts to change the data to match the new schema. There are tools that claim to make migrations easy, but they often run into trouble if the schemas are not the same.

Some older solutions involve “rolling back” the changes or “rolling forward” all databases to the newest schema before the move. Both options can be risky. Rolling back can mean lost data or features. Rolling forward means you have to update everything at once, which is hard if you have lots of customers using your app.

There are also ideas about “compatibility rules.” This means setting strict rules so that, even when you update the schema, you don’t break anything. For example, you might say: don’t delete columns, don’t change the names of tables, and don’t touch the main keys that link data together. While these rules help, they can slow down progress. Developers may not be free to make the changes they really need.

Another common trick is to use “data mapping” tools. These tools try to match the data from the old schema to the new one, changing things on the fly. But these tools can be slow, and they often don’t handle big changes well. You might end up with errors or missing data, especially when moving lots of information.

A key limitation in all these old ways is that they don’t handle the problem of different update schedules very well. If the public cloud is always moving ahead, and the secure cloud is behind, you’re stuck. You can’t wait forever for the schemas to line up. And if you try to force the update, you risk breaking things.

The new patent takes a different approach. Instead of trying to force both clouds to update at the same time, or making complicated scripts, it introduces an “in-between” step: the intermediate cloud. The idea is simple but powerful. When you want to move your data, you first move it to this special place. Here, the schema is frozen—no changes allowed. You wait until the destination cloud catches up. Then, when both schemas match, you move the data to the final cloud. This clever pause lets you avoid all the messy problems of mismatched updates.

This is different from prior art because it doesn’t require both clouds to change their update schedules. It doesn’t ask developers to follow new, strict rules that might slow down their work. It doesn’t rely on risky scripts or data mapping. Instead, it works with the existing cloud schedules and gives you a safe place to wait until everything lines up. This makes migrations safer, with less downtime and fewer errors. It’s a simple idea, but it solves a hard problem that no one has handled this way before.

Invention Description and Key Innovations

Let’s break down how this new method works, using simple words and real-world examples.

Suppose you’re a company using a public cloud like AWS. Your app and its database live there. Every week, the cloud provider updates the database schema to add new features or fix bugs. Now, you get a contract with the government, and you need to move your app and data to a FedRAMP-approved cloud. This cloud only updates its schema every few months, to make sure everything is secure and tested.

Here’s how the patent’s method helps you make this move:

Step 1: Identify the Data to Move
You pick the database that needs to move. It could be your customer list, your sales data, or anything else.

Step 2: Move to the Intermediate Cloud
Instead of moving straight to the destination cloud, you first move the database to a special spot: the intermediate cloud. This is like a waiting room. Here, the schema is frozen. No updates happen to the database structure while it’s in this spot. This makes sure it doesn’t get out of sync with the destination cloud, which might still be behind on updates.

Step 3: Wait for the Destination Cloud to Catch Up
While your database waits in the intermediate cloud, you keep an eye on the update schedule for the destination cloud. When the destination cloud finally updates its schema, it now matches the schema of your database in the intermediate cloud.

Step 4: Update Both Schemas Together
At the next scheduled update, both the intermediate database and the destination cloud’s schema are updated at the same time. This ensures that both have the same structure.

Step 5: Final Move
Now that both schemas match, you move the database from the intermediate cloud to the destination cloud. There are no more mismatches. Your app works as expected, and you don’t have to worry about data loss or broken features.

Step 6: Clean Up
After the move, the intermediate cloud can be shut down or used for the next migration.

This approach brings several key innovations:

No More Schema Mismatches: Because you freeze the schema in the intermediate cloud and wait for the destination to catch up, the database structure always matches at the time of the final move. This reduces risk and makes the move smoother.

Flexible for Different Schedules: The method works whether the source cloud updates more often or less often than the destination. It doesn’t matter if you’re moving from public to private, or private to public—the same steps apply.

Works with Security Rules: For moves to secure clouds, like FedRAMP, there are often extra checks and waiting periods. The intermediate cloud gives you a place to hold the database while these checks happen, without risking new changes sneaking in and breaking things.

Minimal Downtime: By planning the move in two stages, companies can keep downtime short. The database only has to be frozen during the move to the intermediate cloud and again during the final move. Both can be scheduled for off-peak hours.

Forward Compatibility: The method supports rules that make sure no important data is lost during the moves. For example, rules can say “don’t delete or rename columns or tables” during the migration window. This keeps your data safe and reliable.

Easy to Automate: The patent describes ways to automate the whole process. Software can track the update schedules, manage the moves, and control the intermediate cloud without much human intervention. This means fewer mistakes and faster migrations.

Reusable Across Cloud Types: Whether you’re using commercial clouds, secure government clouds, or anything in between, the approach works. It even allows for cases where the intermediate cloud is actually hosted inside the source cloud, making setup simple.

This method is more than just a technical fix. It’s a new way to think about database migration. Instead of forcing everything to change at once or risking errors, it uses time and planning to make sure everything lines up. It’s like a relay race, where the baton is passed smoothly from one runner to the next, without tripping or dropping it.

For companies, this means less stress, lower costs, and more reliable moves. For cloud providers, it means they can offer migration services that work even when their update schedules don’t match other providers. For everyone, it means safer, faster, and more predictable cloud migrations.

Conclusion

Migrating databases between clouds is a big challenge, especially when each cloud has its own way and timing for updating the database schema. The old ways of handling this were slow, risky, and often led to problems. The new method described in this patent application changes the game. By introducing an intermediate cloud that freezes the schema and waits for the destination to catch up, it offers a smart, safe, and efficient way to handle migrations, even when clouds update on very different schedules.

This method stands out because it doesn’t require risky scripts, manual fixes, or forcing everyone to update at the same time. It works with all cloud types and update schedules and is designed to be automated, reducing human error. As more companies move to the cloud and need to meet strict security rules, this new approach will become even more important.

If your business is facing a complicated migration, this patent points to a future where you don’t need to worry about schema mismatches, long downtimes, or lost data. With this technology, cloud migrations can be as smooth as flipping a switch, bringing you peace of mind and keeping your customers happy.

Click here https://ppubs.uspto.gov/pubwebapp/ and search 20250363079.