Protheus and the Cloud: Migrating Without Stopping Operations
Migrating Protheus to the cloud is often treated as a single event: you pick a date, everyone crosses their fingers, and if something fails, operations stop. That format exists because of a lack of planning, not because the migration itself is inherently risky.
The first step is separating what changes at each stage. Infrastructure (a physical server to a cloud VM) is one change. The database (version, engine, tuning) is another. Connectivity with branch offices and external integrations is a third. Treating all three as a single migration is what turns a weeks-long project into a high-risk cutover.
With infrastructure separated, the safest strategy is to keep production running while the new environment replicates data and processes in parallel, without writing back. This lets you compare reports, response times, and critical routines (tax closing, invoicing) before any real cutover.
Reversibility is what makes this calm: if the new environment runs two weeks in parallel without issues, the final cutover becomes a low-risk event, because it was already tested with real data. If a problem shows up, the old environment is still there, untouched.
The cost and observability gains from the cloud are real, but they only pay off when operations don't feel the transition. A well-executed migration is one the system's users don't even notice happened.