For engineers and technical leads at Indian startups moving from AWS S3 to IBEE's S3-compatible object storage.
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, 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, database backup tools.
The migration is: copy data from AWS S3 to IBEE, update your endpoint URL and credentials, verify, cutover. No application code changes 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.
Before You Start: What You Need
From AWS: Your AWS Access Key ID and Secret Access Key with read permissions on the source buckets. The region your S3 buckets are in (ap-south-1 for Mumbai).
From IBEE: Your IBEE Access Key and Secret Key. Your IBEE endpoint URL. These come from your IBEE dashboard after creating a bucket.
Tools: rclone installed on a machine with good connectivity to both AWS and IBEE. For large datasets, run the migration from an EC2 instance in ap-south-1 — this eliminates egress costs on the AWS side (same-region traffic is free) and maximises throughput.
Step 1 — Create Your Buckets on IBEE
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 — it will look something like https://s3.ibee.in or the endpoint 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 and one for IBEE.
Run rclone config and create a remote named awss3 with the following settings:
Then create a second remote named ibee:
The Provider: Other setting combined with the custom endpoint is what makes rclone work with any S3-compatible provider including IBEE.
Step 3 — Run a Dry-Run First
Before copying any data, run rclone with the --dry-run flag to verify it can read your source bucket and would write to the destination correctly:
Review the output. You should see a list of files that would be copied. If you see authentication errors, check your credentials. If you see no files listed, check the bucket name.
Step 4 — Copy the Data
Once the dry run looks correct, run the actual sync:
The --transfers 32 flag runs 32 parallel file transfers, which significantly speeds up migration of buckets with many small files. The --s3-chunk-size 64M flag uses 64 MB chunks for multipart uploads of large files.
For very large buckets (multi-terabyte), consider running the sync in a tmux or screen session so it survives any SSH disconnection. You can re-run the sync command at any time — rclone will skip files that already exist at the destination and only copy the delta.
Step 5 — Verify the Copy
After the sync completes, run rclone's check command to verify that source and destination match:
This compares checksums of every file on both sides. If the check passes with zero errors, your data is identical on both storage providers.
Step 6 — Update Application Configuration
This is where S3 compatibility makes the migration trivial. In your application configuration, you need to change three values:
The endpoint URL — from AWS's S3 endpoint to IBEE's endpoint URL.
The access key ID — from your AWS key to your IBEE key.
The secret access key — from your AWS secret to your IBEE secret.
If you are using environment variables (which you should be), this is a three-line change in your .env file or secrets manager. If you are using AWS SDK, add the endpoint parameter to your S3 client configuration pointing to IBEE's endpoint, and set forcePathStyle: true.
Example in Node.js AWS SDK v3:
The forcePathStyle: true setting is important — it ensures the SDK constructs S3 URLs in path format (endpoint/bucket/key) rather than virtual-hosted format (bucket.endpoint/key), which is required for non-AWS S3-compatible providers.
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 read and write operations work correctly — uploads, downloads, presigned URL generation, multipart uploads, lifecycle policies if you use them.
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, you still have the AWS bucket as fallback.
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 to your IBEE bucket endpoint. The process depends on your CDN provider but is typically a one-field change in the origin configuration.
If you are using Amazon CloudFront with your S3 bucket, you can continue using CloudFront by updating the origin to IBEE's endpoint, or switch to a CDN that is closer to your Indian users. IBEE's sub-5ms origin latency for Indian users means the CDN's job gets easier regardless of which 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 you are done.
Keep the AWS bucket alive for 30 days after cutover as a fallback. After 30 days with no issues, you can delete it.
What to Expect After Migration
Egress costs drop to Rs.2/GB from Rs.6.50–11/GB on AWS. For most Indian startups this is the most immediately visible change. The first full month's bill after migration will reflect the difference.
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.