When your finance system moves to the cloud: keeping the applications around it working

The vendor's project plan covers the ledger. It rarely covers the applications your organization built around the ledger over the years. Those are the ones that stop working on the first day. When a client's finance system moved to the cloud, we built a bridge so the applications kept posting and reading as before. The steps below cover what this kind of work involves.

1. Find every application that touches the finance database

Make a list before anything else. Include the obvious systems and the quiet ones.

• Grant and program systems that post expenses, advances or allocations.
• Payroll or timesheet systems that post salary costs to projects.
• Procurement or travel systems that create commitments.
• Reporting databases and dashboards that read balances and transactions.
• Spreadsheets with a live connection to the finance database. Ask the finance team to check their own files.

For each one, record whether it reads, writes, or both, and which tables or views it uses. The people who built them may have left, so read the connection settings rather than relying on memory.

2. Understand why the move breaks them

On premises, those applications connect to the finance database directly. They run SQL against its tables, often with an account that was set up years ago. In the cloud, that database is no longer yours to reach. The vendor exposes a connector or API instead, and direct database connections are refused. Every application on your list that uses a direct connection will fail, whether it writes postings or only reads a balance.

Infor SunSystems is one example. Applications that once wrote to its on-premises database have to send postings through the vendor's connector once the system is in the cloud.

3. Send postings through the vendor's connector

Each application that writes to the ledger needs a new path. Instead of inserting rows, it hands a posting to the connector and waits for an answer. Agree with the vendor on what the connector accepts, how it reports a rejected posting, and how it behaves during busy periods. Build the new path so that a failed posting is logged and retried, and so finance staff can see what did not go through.

4. Keep reads working with a synced copy

Reports, lookups and validation checks still need to read the ledger. Rewriting all of them against the connector at once is usually too much change in one step. The alternative is a local copy of the finance data that syncs from the cloud on a schedule. Reading applications point at the copy, and most of them need no other change. Agree on the sync frequency with the finance team, and show the time of the last sync on any report that uses the copy.

5. Test month-end and payroll in full

One successful posting does not prove the path works. Run a complete month-end cycle in a test environment with real volumes. Run a payroll cycle too, because it posts to many projects at once and exposes mapping errors. Compare the postings that arrive in the cloud ledger with the source applications, line by line. Run the same reports from the old database and from the synced copy and reconcile the totals. Have finance staff sign off before the live cutover.

6. Plan to remove the interim copy

The synced copy is a bridge. It keeps the organization working during the move, but it also adds a second place where finance data lives. Once the applications are stable, set a date to review which of them can read from the connector directly. Retire the copy when the last one has moved.

Read more about our finance integration and reporting work, including Infor SunSystems on premises and in the cloud.