Choosing cloud hosting for an ERP, customer portal or internal application is an operating decision. A server specification tells you little about who will restore the service, whether integrations will keep running during a release, or how the bill changes when files and transactions accumulate. A useful hosting proposal answers these questions alongside its technical design.
Start with a description of the application and the people relying on it. Then compare options against the same workload and responsibilities. This makes a managed service, a dedicated environment and a simpler deployment easier to assess without assuming that the most complex architecture is the best fit.
Describe the workload in business terms
Record active users, busy periods, transaction patterns, file storage and background tasks. Distinguish concurrent activity from total registered accounts. An ERP used by fifty people at different times has a different workload from fifty users simultaneously importing documents and running reports.
Include operations that are easy to miss: scheduled reconciliations, large exports, image processing, API retries and month-end reporting. Identify any dependency that limits the workflow even when the application server has spare capacity.
Define a representative performance test with a realistic dataset and a specific completion condition. Measure the whole workflow, including queues and external responses. A fast login page does not demonstrate that a stock import finishes within the agreed window. For application design considerations, read the enterprise software planning guide.
Assign responsibility for the complete service
Create a responsibility table for hosting accounts, application releases, database changes, security updates, certificates, domain renewal, monitoring and incidents. Name the party responsible for each task and the person who can authorize emergency changes.
Clarify what the hosting provider operates and what remains with your team or development supplier. For example, a managed database does not by itself establish who diagnoses a failed ERP migration or reconciles transactions after an integration outage.
Keep an account inventory with the business owner, access method and recovery contact. Agree how staff departures and supplier changes affect access. The company should be able to identify the accounts required to operate its own system without relying on one individual's memory.
Turn recovery expectations into a test
Ask the process owner how much interruption the business can tolerate and which records would be difficult to recreate. Use those answers to set recovery time and data-loss objectives for each important workflow.
AWS reliability guidance on backups covers data, application and configuration backups, together with periodic recovery checks. These are useful questions when reviewing any hosting proposal; an AWS deployment is not required to discuss them.
Consider a fictional distributor whose portal receives orders throughout the day. Restoring its database is only one step. The team also needs to establish which orders reached the warehouse, which customer acknowledgements were sent and which queued tasks may run again. A recovery exercise should check those business outcomes before normal processing resumes.
Document the restore date, the environment used, the recovered record range, the measured duration and the reconciliation result. Record who can approve reopening the service. Keep customer-facing messages and the escalation contact in the operating plan.
Compare costs using explicit assumptions
Ask each supplier to price the same scenario. Separate recurring infrastructure, storage growth, backups, monitoring, licenses, support and implementation. Identify usage-sensitive charges and the person who reviews them.
Include development and testing environments if the release process needs them. Ask what happens when an import temporarily requires more capacity, when a large archive is downloaded, or when retention requirements change. A quote without these assumptions may be difficult to compare even if its monthly headline looks attractive.
Set an agreed review point based on observed workload. Capacity decisions should use measurements from the application and its dependencies. More resources may help a saturated component, but they will not correct a report that repeatedly performs unnecessary work.
Plan deployment, maintenance and exit
Define release approval, rollback conditions and a maintenance window that fits the business. Specify how pending jobs and integrations are handled during a change. The application security planning guide provides further questions about access and delivery evidence.
Before signing, ask how the company receives its data, application source where contractually included, configuration documentation and account handover. Agree the format and a practical method for checking a sample export. List dependencies that would need replacement if hosting changes.
Bring this workload brief to a discussion of cloud infrastructure and DevOps. If the application itself needs redesign, compare custom software development and ERP implementation. Contact Tarawud with your current system, operating hours and recovery priorities to define an appropriate review scope.
