## TL;DR

The import ID you gave does not match any real object the provider can see. Either the ID is wrong, the provider is pointed at the wrong region/account/endpoint, or the object was already deleted. Verify the object exists with the provider's CLI, fix the ID or provider config, and retry the import.

## The error

```text
Error: Cannot import non-existent remote object

While attempting to import an existing object to "module.sql_server.azurerm_mssql_server.SqlServer",
the provider detected that no object exists with the given id. Only pre-existing
objects can be imported; check that the id is correct and that it is associated
with the provider's configured region or endpoint, or use "terraform apply" to
create a new remote object for this resource.
```

## Steps to fix

1. Verify the object exists independently of Terraform, e.g. `aws ec2 describe-instances --instance-ids [id]` or the cloud console.
   - Expected: you confirm whether the object is really there.
2. Check the import ID format against the provider docs: many resources need full ARNs or compound IDs, not short names.
   - Expected: your ID matches the documented import format.
3. Check the provider configuration Terraform used: region, profile, endpoint, subscription. A correct ID in the wrong region reads as non-existent.
   - Expected: provider points at the same place the object lives.
4. Fix the `import` block's `id` (or the `terraform import` argument) and re-run `plan`.
   - Expected: import proceeds to the refresh step.

## When to use this

- `terraform plan` with an `import` block, or `terraform import`, fails with `Cannot import non-existent remote object`.

## When NOT to use this

- `Invalid resource instance data in state` is a provider-version/state decoding problem, not a missing object. If the object genuinely does not exist and you want it, remove the import block and let `apply` create it.

## Compatibility

- Import blocks: Terraform 1.5+. `terraform import` CLI: all versions. Behavior is provider-driven.

## Root cause

Import asks the provider to read an existing remote object by ID. If the read returns not-found (wrong ID format, wrong region/account, deleted object, or eventual-consistency lag after creation), the provider reports it and Terraform aborts rather than creating something the config did not ask for.

## Edge cases

- Right after creating an object out-of-band, retry: some APIs are eventually consistent.
- Cross-account/assume-role setups: the ID may exist in an account your credentials cannot see.
- `for_each` imports need one import block per instance key; a single block with a wrong key fails the same way.