No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

To which resource(s) does it happen? Do you know which fields may be different?
It seems that the diff doesn’t show that, yet: <https://pulumi-community.slack.com/archives/C84L4E3N1/p1574274572026200>

&gt; In order to
&gt; successfully import a resource, its desired configuration (i.e. its
&gt; inputs) must not differ from its actual configuration (i.e. its state)
&gt; as calculated by the resource’s provider.
&gt; <https://github.com/pulumi/pulumi/pull/2893#issue-293527337>
That’s intended as a gate to not accidentally overwrite it with `pulumi up --yes`: <https://github.com/pulumi/pulumi/pull/2893#issuecomment-509771727>

I tested this with `Service` and `Deployment` Objects so far.

I can see precisely which fields differ, pulumi offers a great view into this. It looks like this:

```warning: inputs to import do not match the existing resource; importing this resource will fail
    = kubernetes:core/v1:Service: (import)
        [id=microservice-example-ihrhjljj]
        [urn=urn:pulumi:dev::pulumi::kubernetes:core/v1:Service::microservice-example]
        [provider=urn:pulumi:dev::pulumi::pulumi:providers:kubernetes::default_1_3_1::04da6b54-80e4-46f7-96ec-b56ff0331ba9]
      ~ spec: {
          ~ selector: {
              ~ tier: "backend" =&gt; "frontend"
            }
        }```

So, when you change the `selector` to `tier: backend` in your code, then the import should work, or?