Why This Migration Is Different
Most cloud migrations require application changes, SDK swaps, new API integrations, and testing cycles measured in weeks. This one does not.
IBEE implements the full Amazon S3 API. Every SDK that works with S3 works with IBEE: AWS SDK v2 and v3, boto3, the AWS CLI, and any language client built on the S3 protocol. Every tool that reads from or writes to S3 works with IBEE: rclone, Terraform's S3 backend, Kubernetes CSI drivers, CI/CD pipeline artifact storage, and database backup tools.
The migration is: copy data from AWS S3 to IBEE, update your endpoint URL and credentials, verify, then cut over. No application code changes are required unless you have hardcoded bucket URLs rather than using environment variables.
A small startup with a few hundred gigabytes of data can complete this migration in a few hours. A larger startup with terabytes of data can run it over a weekend with zero user-facing impact. We have run this process for teams ranging from a few gigabytes to multiple terabytes, and the pattern is consistent: the data copy takes the most time, the configuration change takes the least.
The diagram below shows the nine-step migration process from start to cutover.
The migration runs in nine steps. Steps 1–5 are data movement. Steps 6–7 are configuration and validation. Steps 8–9 are cutover and cleanup.
Step 1: Create Your Buckets on IBEE
Before starting, gather three things. From AWS, you need your Access Key ID and Secret Access Key with read permissions on the source buckets, and the region your buckets are in (ap-south-1 for Mumbai). From IBEE, you need your Access Key, Secret Key, and endpoint URL, all available from your IBEE dashboard after creating a bucket. For tooling, install rclone on a machine with good connectivity to both providers. For large datasets, run the migration from an EC2 instance in the Mumbai region: same-region traffic to AWS is free, and the throughput to IBEE will be maximised.
Log into your IBEE dashboard and create a bucket with the same name as your AWS S3 bucket, or a new name if you prefer. Note the endpoint URL shown in your dashboard. If you are migrating multiple buckets, create all of them before starting the data copy.
Step 2: Configure rclone
rclone is the most reliable tool for S3-to-S3 migrations. Install it on your migration machine, then configure two remotes: one for AWS S3 using the ap-south-1 region and your AWS credentials, and one for IBEE using the S3-compatible provider type with IBEE's endpoint URL and your IBEE credentials. The IBEE remote requires the provider set to "Other" (the generic S3-compatible setting) with the custom endpoint pointing to IBEE. Full rclone remote configuration examples for IBEE are available at ibee.ai/docs.
Step 3: Run a Dry Run First
Before copying any data, run rclone in dry run mode, specifying the AWS remote and source bucket as the origin and the IBEE remote and destination bucket as the target. The dry run reads the source and shows what would be copied without transferring anything. Review the output: you should see a list of files that would be copied. Authentication errors indicate a credentials problem. No files listed indicates a bucket name mismatch. Resolve any issues before proceeding to the actual copy.
Step 4: Copy the Data
Once the dry run looks correct, run rclone copy with 32 parallel transfers and a 64 MB chunk size for multipart uploads of large files. These settings significantly speed up migration of buckets with many small files and large objects respectively. Full rclone copy configuration options for IBEE are available at ibee.ai/docs.
For very large buckets in the multi-terabyte range, run the copy inside a tmux or screen session so it survives any SSH disconnection. You can re-run the copy command at any time: rclone will skip files that already exist at the destination and copy only the delta. This makes the process safe to interrupt and resume.
Step 5: Verify the Copy
After the sync completes, run rclone check between the source and destination. This command compares the checksum of every file on both sides. If the check passes with zero errors, the data is byte-for-byte identical on both storage providers and the copy is complete.
Step 6: Update Application Configuration
This is where S3 compatibility makes the migration straightforward. In your application configuration, three values need to change: the endpoint URL from AWS's S3 endpoint to IBEE's endpoint URL, the access key from your AWS key to your IBEE key, and the secret access key from your AWS secret to your IBEE secret.
If you are using environment variables, this is a three-line change in your environment file or secrets manager. If you are using the AWS SDK directly, set the endpoint parameter in your S3 client configuration to point at IBEE's endpoint and set the path-style flag to true. The path-style setting is important: it instructs the SDK to construct storage URLs in path format rather than virtual-hosted format, which is required for non-AWS S3-compatible providers. Full SDK configuration examples for AWS SDK v2, v3, boto3, and other common clients are available at ibee.ai/docs.
Step 7: Run in Parallel Before Cutover
Before pointing production traffic at IBEE, run your application in a staging or shadow environment against the IBEE bucket. Verify that all operations work correctly: uploads, downloads, presigned URL generation, multipart uploads, and any lifecycle policies you use.
For critical production systems, consider a one-week parallel run: keep writing to both AWS S3 and IBEE simultaneously and serve reads from IBEE. If anything behaves unexpectedly, the AWS bucket remains as a fallback with no data loss.
Step 8: CDN Reconfiguration (If Applicable)
If you are serving files through a CDN with your S3 bucket as the origin, update the CDN origin to point at your IBEE bucket endpoint. This is typically a one-field change in the CDN's origin configuration. If you are using Amazon CloudFront, you can continue using it by updating the origin to IBEE's endpoint, or switch to a CDN geographically closer to your Indian users. IBEE's sub-5ms origin latency for Indian users reduces CDN origin-fetch time regardless of which CDN provider you use.
Step 9: Final Cutover and Cleanup
Once you are confident the IBEE environment is running correctly in production, remove the dual-write configuration if you implemented it and stop writing to the AWS S3 bucket. Run one final rclone sync to pick up any files written to AWS during the parallel run period, verify with rclone check, and the migration is complete.
Keep the AWS bucket alive for 30 days after cutover as a fallback. After 30 days with no issues, delete it.
What to Expect After Migration
Egress costs drop from Rs.10.37/GB ($0.1093/GB) on AWS to Rs.2/GB ($0.021/GB) on IBEE. For most Indian startups this is the most immediately visible change on the first full month's bill after migration.All USD equivalents in this article use a conversion rate of Rs.94.91 per dollar as of May 2026.
Latency for Indian users typically improves or stays the same, given IBEE's India-first infrastructure topology.
Application behaviour is unchanged. Every S3 operation that worked before works identically on IBEE.
Getting Help
IBEE's team is available at sales@ibee.in for migration support. For large datasets or complex multi-bucket migrations, the team can assist with migration planning and provide dedicated support during the cutover window.
